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Description 

The present invention relates to secure management of keys using control vectors. 

The cryptographic transformation of data is ordinarily defined by a selected algorithm, or procedure, under the 
s control of a key. Since the algorithm is normally public knowledge, protection of the transformed, or enciphered, data 
depends on secrecy of the key. Thus the key must be kept secret to prevent an opponent from simply using the known 
algorithm and key to recover the enciphered data. The protection of the data therefore hinges on the protection of secret 
keys. 

Key Management encompasses the facilities, functions and procedures in a cryptographic system to handle cryp- 
io tographic keys and key-related information in such a way as to protect the secrecy and integrity of the keys. 

In order to support the primary cryptographic requirements of a user or host system, the system Key Management 
facility usually supports several capabilities including, Key Installation, Key Storage, Key Generation, and Key Distribu- 
tion for both importing and exporting keys. 

In all cases the general objective is to prevent unauthorised disclosure or modification of cryptographic keys. 
'5 Since enciphered data may be exchanged by systems employing the same cryptographic algorithm, the ability to 

exchange a secret key or keys may be necessary. In order to protect privacy of a secret key during its shipment from 
the key originator to the intended recipient, the key itself must be enciphered under another secret key (already shared 
by the two parties). Key distribution protocols must be defined to support compatible, secure exchange of keys among 
cryptographic systems. 

20 The storage of keys on insecure media (i.e., storage not within a secure area) requires that keys themselves be 

enciphered. The Master Key concept is one in which all keys used by a cryptographic system are stored in enciphered 
form under a single key called the Master Key. The Master Key itself must be protected from disclosure or modification. 
Non-cryptographic means are usually provided to protect the Master Key (such as physical access control). 

A discussion of current techniques for the generation and distribution of cryptographic keys is given in the article in 
25 the ICL Technical Journal, vol. 4, No. 2, November 1984, pp 146-158. 

The prior art has failed to provide a practical and flexible Key Management system which maintains high data security 
standards. 

It is therefore an object of the invention to provide integrity for the cryptographic algorithm and certain higher-level 
cryptographic functions. 
30 This object is achieved by the invention claimed in claim 1 . 

Using the invention, provision can be made for protection of the integrity of stored or distributed keys; prevention 
of the misuse of stored or distributed keys (e.g., using a privacy key as an authentication key); restricting the usage of 
stored or distributed keys (e.g., authentication verification only); providing for secure installation of the Master Key and 
other manually-installed key-encrypting keys; and secure generation of new key-encrypting keys and data encrypting 
35 keys. 

An embodiment of the invention is disclosed hereinafter which is referred to herein as the Cryptographic Architecture 
(CA), and is described implemented in a data processing system. The system executes a program which outputs cryp- 
tographic service requests for the management of cryptographic keys which are associated with control vectors defining 
the functions which each key is allowed-by its originator to perform. The arrangement validates that key management 

40 functions requested for a cryptographic key by the program have been authorised by the originator of the key. 

The cryptographic facility is characterised by a secure boundary through which passes an input path for receiving 
the cryptographic service requests, cryptographic keys and their associated control vectors, and an output path for 
providing responses thereto. There can be included within the boundary a cryptographic instruction storage coupled to 
the input path, a control vector checking means and a cryptographic processing means coupled to the instruction storage, 

45 and a master key storage coupled to the processing means, for providing a secure location for executing key manage- 
ment functions in response to the received service requests. 

The cryptographic instruction storage receives over the input path a cryptographic service request for performing 
a key management function on a cryptographic key. The control vector checking means has an input coupled to the 
input path for receiving a control vector associated with the cryptographic key and an input connected to the cryptographic 

so instruction storage, for receiving control signals to initiate checking that the control vector authorises the key management 
function which is requested by the cryptographic service request. 

The control vector checking means has an authorisation output connection to an input of the cryptographic process- 
ing means, for signalling that the key management function is authorised, the receipt of which by the cryptographic 
processing means initiates the performance of the requested key management function with the cryptographic key. 

55 The arrangement further includes a cryptographic key storage means coupled to the cryptographic facility over the 

input and output paths, for storing the cryptographic key in an encrypted form in which the cryptographic key is encrypted 
under the storage key which is a logical product of the associated control vector and a master key stored in the master 
key storage. 
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For example, the cryptographic instruction storage can receive over the input path a cryptographic service request 
for recovering the cryptographic key from the cryptographic key storage means and the control vector checking means 
outputs in response thereto, an authorisation signal to the cryptographic processing means that the function of recovering 
the cryptographic key is authorised. The cryptographic processing means then operates in response to the authorisation 

5 signal, to receive the encrypted form of the cryptographic key from the cryptographic key storage means and to decrypt 
the encrypted form under the storage key which is a logical product of the associated control vector and the master key 
stored in the master key storage. 

The control vector includes fields defining authorised types of cryptographic functions including key management 
functions, data encryption/decryption functions and PIN processing functions. The associated control vector also in- 

10 eludes fields defining export control and usage of the keys. These various fields enforce the separation of several types 
of keys which have intended uses which should be made mutually exclusive in order to maintain the security of the 
system. 

The disclosed arrangement enables the flexible control of many cryptographic key management functions in the 
generation, distribution and use of cryptographic keys, while maintaining a high security standard. 
is Clearly, from another aspect, the present invention also provides a system or apparatus for performing the method. 

The present invention will be described further by way of example with reference to an embodiment thereof as 
illustrated in the accompanying drawings, in which:- 



20 



25 



Fig. 1 is a System Diagram showing the major components of the Cryptographic Facility (CF); 

Fig. 2 is a System Diagram showing the components of the CF, software driver CFAP and cryptographic application 
programs; 

Fig. 3 shows where Control Vectors are applied in various inter-system communications scenarios; 
Fig. 4 illustrates the fundamental cryptographic key separation; 
Fig. 5 illustrates data key separation; 
30 Fig. 6 illustrates PIN key separation; 

Fig. 7 illustrates key Encrypting Key separation; 

Fig. 8 summarises the relative priority of implementing the various types of key separation; 

35 

Fig. 9 summarises the separation provided for each of the defined key types; 
Fig. 10 shows the general format for Control Vectors (CV); 
40 Fig. 1 1 shows the CV format for Privacy keys; 

Fig. 12 illustrates the method of encrypting a key K under the Master Key with an Extended Control Vector; 
Fic 

45 



50 



55 



shows 


the 


CV format 


for 


MAC keys; 


shows 


the 


CV format 


for 


Data Compatibility keys; 


shows 


the 


C V format 


for 


Data Translate (XL ATE) keys; 


shows 


the 


C V format 


for 


ANSI Data keys; 


shows 


the 


CV format 


for 


PIN-encrypting keys; 


shows 


the 


CV format 


for 


PIN-generating keys; 


shows 


the 


CV format 


for 


Key Encrypting Key (KEK) Sender; 


shows 


the 


CV format 


for 


KEK Receiver; 
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Fig. 21 shows the CV format for ANSI KEKs; 
Fig. 22 shows the CV format for Key Parts; 
5 Fig. 23 shows the CV format for Intermediate ICVs; 

Fig. 24 shows the CV format for Tokens; 
Fig. 25 is a Block Diagram of the Encode instruction; 

10 

Fig. 26 is a Block Diagram of the Decode instruction; 
Fig. 27 is a Block Diagram of the Encipher instruction; 
is Fig. 28 is a Block Diagram of the Decipher instruction; 

Fig. 29 is a Block Diagram of the Generate Message Authentication Code (Genmac) instruction; 
Fig. 30 is a Block Diagram of the Verify Message Authentication Code (Vermac) instruction; 

20 

Fig. 31 is a Block Diagram of the Translate Cipher Text instruction; 

Fig. 32 lists the types and subtypes of keys which may be generated for each mode of the Generate Key Set (GKS) 
instruction; 

25 

Fig. 33 is a Block Diagram of the Generate Key Set instruction; 

Fig. 34 shows the valid combinations of CV Types for the pair of keys generated by the GKS OP-OP mode; 

30 Fig. 35 shows the valid combinations of Left versus Right CV attributes of Importing or Exporting KEKs used in the 

various modes of GKS. "Key Form and Link Control attributes are specified; 

Fig. 36 shows the valid combinations of CV Key Forms and Link Control for pairs of Imported or Exported keys 
generated by various modes of GKS; 

35 

Fig. 37 shows the valid combinations of CV Types for the pair of keys generated by GKS OP-IM mode; 
Fig. 38 is a Block Diagram of the Re-encipher Form Master Key instruction; 
40 Fig. 39 is a Block Diagram of the Re-encipher to Master Key instruction; 

Fig. 40 is a Block Diagram of the Keygen instruction; 
Fig. 41 is a Block Diagram of the Encipher Under Master Key instruction; 

45 

Fig. 42 is a Block Diagram of the Translate Key instruction; 

Fig. 43 shows the valid combinations of Left versus Right CV Key Form attributes for the Importing and Exporting 
KEKs used in the Translate Key instruction; 

so 

Fig. 44 shows the Block Diagram for Mode 0 (Key Mode) of the Re-encipher to New Master Key instruction; 
Fig. 45 shows the Block Diagram for Mode 1 (Token Mode) of the Re-encipher to New Master Key instruction; 
55 Fig. 46 shows the Block Diagram for Mode 0 (Key Mode) of the Re-encipher to Current Master Key instruction; 

Fig. 47 shows the Block Diagram for Mode 1 (Token Mode) of the Re-encipher to Current Master Key instruction; 
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Fig. 48 and Fig 49 show the Block Diagram of the ANSI Create Partial Notarising Key instruction; 

Fig 50 shows the Block Diagram for the ANSI Re-encipher From Master Key (ARFMK) instruction; 

s Fig. 51 shows the valid CV Usage attributes for a data key to be exported by ARFMK; 

Fig. 52 shows the valid combinations of CV Type and Key Form for the Left and Right halves of the exporting KEK 
versus the corresponding attributes of the key to be exported in the ARFMK instruction; 

10 Fig. 53 shows the valid C V Usage attributes which may be specified for the CSM MAC key produced as a by-product 

of ARFMK; 

Fig. 54 shows the block diagram for the ANSI Re-encipher to Master Key (ARTMK) instruction; 

'5 Fig. 55 shows the valid CV Usage attributes for a data key to be imported by ARTMK; 

Fig. 56 shows the valid combinations of CV Type and Key Form for the Left and Right halves of the importing KEK 
versus the corresponding attributes of the key to be imported in the ARTMK instruction; 

20 Fig. 57 shows the valid CV Usage attributes which may be specified for the CSM MAC key produced as a by-product 

of ARTMK; 

Fig. 58 and Fig. 59 show the Block Diagram for the ANSI Translate Key (AXLTKEY) instruction; 

25 Fig. 60 shows the valid CV Usage attributes which may be specified for the CSM MAC key produced as a by-product 

of AXLTKEY; 

Fig. 61 shows the Block Diagram for the ANSI Combine KDs (ACOMBKD) instruction; 

30 Fig. 62 shows the valid CV Usage attributes for the first of two. "partial" CSM MAC keys input to the ACOMBKD 

instruction; 

Fig. 63 shows the valid CV Usage attributes for the second of two "partial" CSM MAC keys input to the ACOMBKD 
instruction; 

35 

Fig. 64 shows the valid CV Usage attributes which may be specified for the CSM MAC key produced by ACOMBKD; 

Figs. 65, 66, 67 and 68 show a mapping from common key management requirements or activities to instructions 
from which these requirements may be satisfied; 

40 

Fig. 69 shows the key state (OP, IM EX) transformations performed by certain instructions. Export and Import Chan- 
nels represent uni-directional avenues of conveyance for keys imported and exported from the Cryptographic Facil- 
ity; 

45 Fig. 70 shows the valid CV types which may be imported or exported on each Channel Type (CV, CV = ), and ANSI); 

Fig. 71 shows the valid combinations of Distribution Modes and CV Link Control attributes; 
Fig. 72 depicts the Key Translation process performed at a node C on behalf of nodes A and B; 

50 

Fig. 73 shows a portion of the Key Encrypting Key Data Set (KDDS) where KEKs are stored; 
Fig. 74 is an ANSI X9.17 System Node Diagram; 
55 Fig. 75 shows the functional interfaces among components within an ANSI X9. 1 7 node; 

Fig. 76 is an ANSI Point-to-Point Environment System Diagram; 
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Fig. 


77 




Fig. 


78 
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Fig. 


79 




Fig. 


80 




Fig. 


82 


10 








Fig. 


83 




Fig- 


84 


15 


Fig. 


85 



Fig. 80 and Fig. 81 show the distribution of Data Keys (KD) in a CCA ANSI X 9.17 implementation in tabular form; 



Figs. 86, 87 and 88 summarise the equations for each of the instructions. 



A flexible key usage control method and apparatus are described, which is referred to herein as the Cryptographic 
20 Architecture (CA). The method enforces strict key separation within the local cryptographic facility and between systems 
(I.e. "on-the-link"). The method uses Control Vectors which force the recipient or user of a key to use the key in a manner 
consistent with the intentions of the originator of the key. 

All keys stored on insecure media outside the cryptographic facility are encrypted under a key formed from a function 
of the Master Key and a specific Control Vector value dictated by the originator of the stored key. The Master Key and 
25 possibly a few other keys are stored in the clear within the physically secure cryptographic facility. At no time does any 
key unintentionally appear in the clear outside the secure cryptographic facility. 

Keys transmitted from one system to another are encrypted under a key formed from a function of a key-encrypting 
key and a specific Control Vector value dictated by the originator (and possibly the sender) of the key. Where such key 
usage control interferes with support for specific key distribution protocols, on-the-link control is not be enforced. 
30 A set of primitive cryptographic functions, or instructions, are defined. These instructions form the basis of the func- 

tional security baseline. Each instruction is specified in terms of its input and output parameters, function description, 
and Control Vector processing. For integrity, the instructions are intended to be implemented completely within the 
secure cryptographic facility. 

A very strong and positive feature of the cryptographic design is the strict adherence to the principle of limited 

35 function. This principle calls for the cryptographic interfaces to be implemented such that only the desired, and antici- 
pated, cryptographic functions are permitted, and nothing else. It is the "nothing else" that is important. It has been found 
that attacks are frequently developed by using the architected interfaces of prior systems in some way not specifically 
required, or called for under the architecture, but which have not been prohibited by the implementation. 

Fig. 1 gives a Block Diagram representation of the data processing system with the cryptographic facility therein. 

40 in Fig. 1 , the data processing system 2 executes a program such as the crypto facility access programs and the appli- 
cation programs illustrated in Fig. 2. These programs output cryptographic service requests for the management of the 
cryptographic keys which are associated with control vectors. The general format for a control vector is shown in Fig. 
1 0. Control vectors define the function which the associated key is allowed by its originator to perform. The cryptographic 
architecture invention herein is an apparatus and a method for validating that key management functions requested for 

45 a cryptographic key by the program, have been authorised by the originator of the key. 

As is shown in Fig. 1 , contained within or associated with the data processing system 2 is a cryptographic facility 4 
which is characterised by a secure boundary 6. An input/output path 8 passes through the secure boundary 6 for receiving 
the cryptographic service request, cryptographic keys and their associated control vectors from the program. The in- 
put/output path 8 outputs responses to those cryptographic requests from the cryptographic facility. Included within the 

so secure boundary 6 is a cryptographic instruction storage 10 which is coupled by units of the bus 1 2 to the input/output 
path 8. A control vector checking units 14 is coupled to the instruction in storage 10 and a cryptographic processing 
units 1 6 is also coupled to the instruction storage 1 0. A master key storage 1 8 is coupled to the cryptographic processing 
unit 16. The cryptographic facility 4 provides a secure location for executing key management functions in response to 
the received service request. 

ss The cryptographic instruction storage 10 receives the input/output path 8 a cryptographic service request for per- 

forming a key management function with a cryptographic key. The control vector checking unit 14 has an input coupled 
to the input/output path 8, for receiving a control vector associated with the cryptographic key. The control vector checking 
unit 14 also has an input connected to the cryptographic instruction storage 10, for receiving control signals to initiate 
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checking that the control vector authorises the key management function which is requested by the cryptographic service 
request. 

The control vector checking unit 1 4 has an authorisation output 20 which is connected to an input of the cryptographic 
processing unit 16, for signalling that key management function is authorised, the receipt of the authorisation signal by 

5 the cryptographic processing unit 1 6 initiates the performance of the requested key management function with the cryp- 
tographic key. A cryptographic key storage unit 22 is coupled to the cryptographic facility 14 over the input/output path 
8. The cryptographic key storage unit 22 stores the cryptographic key in an encrypted form in which the cryptographic 
key is encrypted under a storage key which is a logical product of the associated control vector and the master key 
stored in the master key storage 18. 

10 An example of recovering an encrypted key from the cryptographic key storage 22 occurs when the cryptographic 

instruction storage 10 receives over the input/output path 8 a cryptographic service request for recovering the crypto- 
graphic key from the cryptographic key storage units 22. The control vector checking unit 1 4 will then output in response 
thereto, an authorisation signal on line 20 to the cryptographic processing unit 16 that the function of recovering the 
cryptographic key is authorised. The cryptographic processing unit 16 will then operate in response to the authorisation 

15 signal on line 20, to receive the encrypted form of the cryptographic key from the cryptographic key storage 22 and to 
decrypt the encrypted form under the storage key which is a logical product of the associated control vector and the 
master key stored in the master key storage 1 8. 

The storage key is the exclusive-OR product of the associated control vector and the master key stored in the master 
key storage 18. Although the logical product is an exclusive OR operation in the preferred embodiment, it can also be 

20 other types of logical operations. 

The associated control vector, whose general format is shown in Fig. 10, is stored with the encrypted form of its 
associated cryptographic key in the cryptographic key storage 22. Since all keys stored on a cryptographic storage 
encrypted under the master key, a uniform method for encryption and decryption of encrypted keys thereon can be 
performed. 

25 The associated control vector, whose general format is shown in Fig. 10, includes fields defining the authorised 

types of cryptographic functions, including key management functions, data encryption/decryption functions and per- 
sonal identification numbers (PIN) processing functions. In the key management applications, the key management 
functions type is designated for the type field. The associated control vector also includes additional fields which can 
define export control for the keys and associated encrypted information and the usage of the keys and associated 

30 encrypted information. 

The arrangement shown in Fig. 1 can perform the generation of a key set, which is a pair of keys having several 
classes of uses. A random number source 26 or a stored random number in the working storage 24 of the cryptographic 
facility 4, has an input connected to the cryptographic processing units over the bus 1 2, for supplying a random number 
thereto. 

35 The cryptographic instruction storage 1 0 will then receive over the input/output path 8 a cryptographic service request 

for the generation of a key pair from the random number output from the random number source 26, with associated 
first and second control vectors C3 and C4. The control vector checking unit 14 will then output in response thereto, an 
authorisation signal on line 20 to the cryptographic processing unit 16 that the function of generating a key pair from the 
random number is authorised. The cryptographic processing unit 16 then operates in response to the authorisation 

40 signal on line 20, to output the random number as a first generated key in an encrypted form in which the random number 
is encrypted in a key which is a logical product of the first associated control vector C3 and a first key K1 . The crypto- 
graphic processing unit 16 then further operates in response to the authorisation signal on line 20, to output the random 
number as a second generated key in an encrypted form in which the random number is encrypted under a key which 
is a logical product of the second associated control vector C4 and a second key K2. There are a variety of combinations 

45 of usages which can be authorised by the control vectors C3 and C4. One combination is for the production of two keys 
which are operational in the local data processing system 2 and, in this case, the first and second keys K1 and K2 are 
the random number and the first and second control vectors C3 and C4 only authorise operational usage within the local 
data processing system 2. A second combination can be for the production of a first generated key which is only oper- 
ational in the local data processor 2 and a second generated key which can be exported to a remote data processing 

50 system 30 just connected to the local system 2, and in this case the first key K1 is the random number and the first 
control vector C3 only authorises operational usage within the local data processing system 2 whereas, the second key 
K2 is a key encrypting key KEK2 and the second control vector C4 authorises exportation to the remote data processing 
system 30. A third case is for the production of a first generated key which can be exported to a first remote data 
processing system 30 connected to the local data processing system 2 and a second generated key which can be 

55 exported to a second remote data processing system 30' connected to the local data processing system 2, and in this 
case, the first key K1 is a key encrypting key KEK1 and the first control vector C3 authorises exportation to the first 
remote data processing system 30, whereas the second key K2 is a key encrypting key KEK2 and the second control 
vector C4 authorises exportation to the second remote data processing system 30'. A fourth combination is for the 
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production of a first generated key which is only operational in the local data processing system 2 and a second generated 
key which can be imported from a remote data processing system 30 connected to the local system 2, and in this case, 
the first key K1 is the random number and the first control vector C3 only authorises operational usage within the local 
data processing system 2, whereas the second key K2 is a key encrypting key KEK2 and the second control vector C4 

5 authorises importation from the remote data processing system 30 to the local data processing system 2. A fifth case 
is for the production of a first generated key which can be imported from a first remote data processing system 30 
connected to the local data processing system 2 and a second generated key which can be exported to a second remote 
data processing system 30' connected to the local system 2, and in this case the first key K1 is a key encrypting key 
KEK1 and a first control vector C3 authorises importation from the first remote data processing system 30, whereas a 

10 second key K2 is a key encrypting key KEK2 and a second control vector C4 authorises exportation to the second 
remote data processing system 30/. 

The arrangement shown in Fig. 1 can perform the operation of re-encipherment from master key function as follows. 
The data processing system 2 is connected over the communications link 28 to a remote data processing 30, with which 
a secret key encrypting key KEK is shared. The cryptographic key storage unit 22 stores the key encrypting key KEK 

is in an encrypted form in which KEK is encrypted under a storage key which is a logical product of an associated control 
vector C1 and the master key. The cryptographic key storage units 22 also stores the cryptographic key as key K in an 
encrypted form in which key K is encrypted under a storage key which is a logical product of an associated control vector 
C2 and the master key. 

The cryptographic instruction storage 10 will receiver over the input/out path 8 a cryptographic service request for 

20 re-enciphering the cryptographic key K from the master key to encipherment under the key encrypting key KEK for the 
purpose of export with an associated control vector C3 to the remote data processing system 30. The control vector 
checking unit 14 will output in response thereto, an authorisation signal on line 20 to the cryptographic processing unit 
16 that the function of re-enciphering the cryptographic key K from the master key to encipherment under the key en- 
crypting key KEK for export is authorised. 

25 The cryptographic processing unit 16 will operate in response to the authorisation signal on line 20, to receive the 

encrypted form of the cryptographic key K from the cryptographic key storage units 22 and to decrypt the encrypted 
form thereof under a storage key which is a logical product of the associated control vector C2 and the master key. The 
cryptographic processing unit 16 will further operate in response to the authorisation signal on line 20, to receive the 
encrypted form of the key encrypting key KEK from the cryptographic key storage unit 22 and to decrypt the encrypted 

30 form thereof under a storage key which is a logical product of the associated control vector C1 and the master key. 

The cryptographic processing unit 16 will then operate in response to the authorisation signal on line 20, to re-en- 
cipher the cryptographic key K under a logical product of the associated control vector C3 and the key encrypting key 
KEK and will output the re-encipher cryptographic key K and the associated control vector C3 for transmission over the 
communications link 28 to the first remote data processing system 30. 

35 The arrangement of Fig. 1 can perform the operation of re-encipherment to the master key function as follows. The 

data processing system 2 is connected over the communication link to the remove data processing system 30 with which 
it shares a secret key encrypting key KEK. The cryptographic key storage units 22 stores the key encrypting key KEK 
in an encrypted form in which KEK is encrypted under a storage key which is a logical product of an associated control 
vector C1 and the master key. 

40 The remote data processing system 30 transmits over the communications link 28 to the local data processing 

system 2 a cryptographic key K enciphered under the key encrypting key KEK with an associated control vector C3. 
The cryptographic instruction storage 10 receives over the input/output path 8 a cryptographic service request for re-en- 
ciphering the cryptographic key K from the key encrypting key KEK to encipherment under the master key with an 
associated control vector C2 for storage in the cryptographic key storage 22. The control vector checking unit 14 then 

45 outputs in response thereto, an authorisation signal on line 20 to the cryptographic processing units 16 that the function 
of re-enciphering the cryptographic key K from the key encrypting key KEK to encipherment under the master key for 
storage, is authorised. The cryptographic processing unit 16 then operates in response to the authorisation signal on 
line 20 to re-encipher the key K from the key encrypting key KEK to encipherment under the master key with the control 
vector C2 and outputs the re-enciphered key K to the cryptographic key storage 22. 

50 The arrangement of Fig. 1 can be further applied to generate a single key as follows. The random number source 

26 has an output connected to the cryptographic processing unit 16 over the bus 12, for supplying a random number 
thereto. The cryptographic instruction storage 10 receives over the input/output path 8 a cryptographic service request 
for the generation of a key from the random number with an associated control vector C1 . The control vector checking 
unit 14 outputs in response thereto, an authorisation signal on line 20 to the cryptographic processing unit 16 that the 

55 function of generating a key from random numbers is authorised. The cryptographic processing unit 16 operates in 
response to the authorisation signal on line 20, through output the random number as a generated key in an encrypted 
form in which the random number is encrypted under a key which is a logical product of the associated control vector 
C1 and the master key. 
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The arrangement of Fig. 1 can further operate to perform a translate key function, as follows. The data processing 
system 2 of Fig. 1 is a local system which is connected over a communications link 28 to a first remote dat processing 
system 30 with which it shares a secret import key encrypting key KEK1. The local data processing system 2 is also 
connected over a communications link 28' to a second remote data processing system 30' with which it shares a secret 
s export key encrypting key KEK2. The cryptographic key storage 22 stores the import key encrypting key KEK1 in an 
encrypted form in which KEK1 is encrypted under a storage key which is a logical product of an associated control vector 
C1 and the master key. The cryptographic storage key 22 stores the export key encrypting key KEK 2 in an encrypted 
form in which KEK2 is encrypted under a storage key which is a logical product of an associated control vector C2 and 
the master key. 

10 The first remote data processing system 30 transmits over the communications link 28 to the local data processing 

system 2 a cryptographic key K enciphered under the import key encrypting key KEK1 with an associated control vector 
C3. The cryptographic instruction storage 1 0 receives over the input/output path 8 a cryptographic request for translating 
the cryptographic key K from encipherment under the import key encrypting key KEK1 to encipherment under the export 
key encrypting key KEK2 with an associated control vector C3 for transmission over the communications link 28' to the 

is second data processing system 30'. The control vector checking unit 14 outputs in response thereto, an authorisation 
signal on line 20 to the cryptographic processing unit 16 that the function of translating the cryptographic key K from 
encipherment under the import key encrypting key KEK1 to encipherment under the export key encrypting key KEK2 is 
authorised. 

The cryptographic processing unit 16 operates in response to the authorisation signal on line 20, to translate the 

20 cryptographic key K from encipherment under the import key encrypting key KEK1 to encipherment under the export 
key encrypting key KEK2 with the associated control vector C3 for transmission over the communications links 28' to 
the second data processing system 30'. 

various restrictions can be applied using the control vectors C1 , C2 and C3 so as to prevent the local data processing 
system 2 from reading or from operating with the key K so that it can be transferred from the originating data processing 

25 unit 30 to the destination data processing unit 30' in a secure manner. 

The arrangement of Fig. 1 can operate to perform a re-encipherment from current master key to new master key 
function, as follows. A current master key storage such as the working storage 24, will store a current master key and 
a new master key can be stored in the master key storage 18, and both the current master key storage 24 and the 
master key storage 18 are coupled to the cryptographic processing unit 16 and the cryptographic facility 4. The crypto- 

30 graphic key storage 22 stores a cryptographic key such as key K in an encrypted form in which key K is encrypted under 
a storage key which is a logical product of an associated control vector C1 and the current master key. The cryptographic 
instruction storage will receive over the input/output path 8 a cryptographic service request for re-enciphering the cryp- 
tographic key K from the current master key to encipherment under the new master key with the associated control 
vector C1 and the control vector checking units will output in response thereto an authorisation signal on line 20 to the 

35 cryptographic processing unit 16 that the function of re-enciphering the cryptographic key K from the current master key 
to encipherment under the new master key, is authorised. 

Cryptographic processing unit 16 will operate in response to the authorisation signal on line 20, to receive the 
encrypted form of the cryptographic key K from the cryptographic storage 22 and to decrypt the decrypted form thereof 
under a storage key which is a logical product of the associated control vector C1 and the current master key. Crypto- 

40 graphic processing unit 16 will then operate in response to the authorisation signal on line 20, to re-encipher the cryp- 
tographic key K under a logical product of an associated control vector C1 and the new master key and output the 
re-enciphered cryptographic key K and the associated control vector C1 to the cryptographic key storage 22. 

The arrangement of Fig. 1 will operate to perform a lowering of the authority specified by a control vector for the 
usage of a key, and this is accomplished as follows. The cryptographic key storage 22 stores the cryptographic key as 

45 key K in an encrypted form in which the key K is encrypted under a storage key which is a logical product of an associated 
control vector C1 and the master key. The associated control vector C1 includes a field which defines export control, 
for example. The cryptographic instruction storage 10 receives over the input/output path 8 a cryptographic service 
request for lowering the control vector authority for the associated control vector C1 and the control vector checking unit 
1 4 outputs in response thereto, an authorisation signal on line 20 to the cryptographic processing unit 1 6 that the function 

50 of lowering the control vector authority for the associated control vector C1 , is authorised. 

Cryptographic processing unit 16 then operates in response to the authorisation signal on line 20, to receive en- 
crypted form of the cryptographic key K from the cryptographic key storage 22 and to decrypt the encrypted form thereof 
under a storage key which is a logical product of the asociated control vector C1 and the master key. The cryptographic 
processing unit 16 then operated in response to the authorisation signal on line 20, to substitute a second control vector 

55 C2 for the associated control vector C 1 , with the second control vector C2 having an export control field with designates 
a lower authority than that which was designated for the previous control vector C1 . The cryptographic processing unit 
16 then operates in response to the authorisation signal on line 20, to encipher the key K under the master key with the 
second control vector C2 and to output the enciphered key K to the cryptographic storage 22 with the second control 
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vector C2. 

The arrangement of Fig. 1 will operate to perform a re-encipherment from master key function with a reduction in 
the export authority for the recipient, in the following manner. The data processing system is a local data processing 
system 2 which is connected to a first remote data processing system 30 with which a secret key encrypting is shared. 

5 The cryptographic storage 22 stores the key encrypting key KEK in an encrypted form in which the KEK is encrypted 
under a storage key which is a logical product on an associated control vector C1 and the master key. The cryptographic 
key storage 22 stores the cryptographic key as key K in an encrypted form in which a key K is encrypted under a storage 
key which is a logical product of an associated control vector C2 and the master key, the associated control vector C2 
having an export field designating a first export authority. The cryptographic instruction storage 10 receives over the 

10 input/output path 8 a cryptographic service request for re-enciphering the cryptographic key K from the master key to 
encipherment under the key encrypting key KEK for export with an associated control vector C3 to the first remote data 
processing 30, the associated control vector C3 having an export field designating a second export authority which is 
less than the first export authority of C2. 

The control vector checking unit 14 outputs in response thereto, an authorisation signal on the line 20 to the cryp- 

15 tographic processing unit 16 that the function of re-enciphering the cryptographic key K from the master key to enci- 
pherment under the key encrypting key KEK for export is authorised. The cryptographic processing unit 16 operates in 
response to the authorisation signal on line 20, to receive the encrypted form of the encrypted key K from the crypto- 
graphic key storage 22 and to decrypt the encrypted form thereof under a storage key which is a logical product of the 
associated control vector C2 and the master key. The cryptographic processing unit 16 operates in response to the 

20 authorisation signal on line 20, to receive the encrypted form of the key encrypting key KEK from the cryptographic key 
storage 22 and to decrypt the encrypted form thereof under a storage key which is a logical product of the associated 
control vector C1 and the master key. 

The cryptographic processing unit 1 6 then operates in response to the authorisation signal on line 20, to re-encipher 
the cryptographic key K under a logical product of the associated control vector C3 and the key encrypting key KEK and 

25 outputs the re-enciphered cryptographic key K and the associated control vector C3 for transmission to the first remote 
data processing system 30. The first remote data processing system now has a lower authority for re-exportation of the 
cryptographic key K because of the lower authority designated in the export field of the associated control vector C3. 

The arrangement of Fig. 1 can further provide for link control operations in the following manner. The associated 
control vector includes a field which defines link control which specifies whether the control vector associated with the 

30 cryptographic key should be omitted from transmission from the local data processing system to remote data processing 
system 30 connected thereto, due to the characteristics of the remote data processing system 3. For example, the 
remote data processing system may not be capable of assimilating and processing control vectors. The control vectors 
which provide for allowing their separation from the associated cryptographic key upon transmission, confer a lower 
security trustworthiness to the resulting operations performed by the associated cryptographic key. In this manner, those 

35 systems such as the local data processing system 2 which are able to make use of the control vectors, have a higher 
security trustworthiness conferred upon them than can be conferred upon remote systems that do not have the capacity 
to use control vectors. The associated control vector can also include a field which specifies whether the key associated 
therewith can be processed by an AN SI -type data processing system as the remote processing 30. 

The arrangement of Fig. 1 has the associated control vector, generally shown in Fig. 10, which includes fields for 

40 enforcing the separation of key encrypting keys based on two mutually exclusive intended uses. Fig. 7 illustrates the 
organisation of separating the various key encrypting keys by their intended usage. For example, mutually exclusive 
intended uses can be for notarised and non-notarised keys. Another form of mutually exclusive intended uses would be 
for first-type key encrypting key which uses control vectors and second-type key encrypting key which does not use 
control vectors. Another example of mutually exclusive intended uses is for a first-type of key encrypting keys to be used 

45 only by senders and a second-type of key encrypting keys to be used only by receivers. Another example of mutually 
exclusive intended uses for which control vectors enforce key separation is for a first-type of key encrypting keys which 
can be used for the generation of key sets and for the translation of keys for shipment without allowing the export of 
existing data keys stored under a master key and a second-type of key encrypting keys which can be used for the 
generation of key sets and the translation of keys for shipment which do allow for the export of existing data keys stored 

50 under a master key. Another example of mutually exclusive intended uses for which the control vector enforces key 
separation is for a first-type of key encrypting keys which can be generated for export only and a second-type of key 
encrypting keys which can be generated for operational use and for export. Another example of mutually exclusive 
intended uses for which control vectors enforce key separation is for a first-type of key encrypting keys which can be 
used in translation without allowing local operational use and a second-type of key encrypting keys which can be used 

55 in translation and also will allow local operational use. Another example of mutually exclusive intended uses for which 
control vectors enforce key separation is for a first-type of key encrypting keys which can be used in the re-encipher 
from master key operation and a second-type of key encrypting key which cannot be used in a re-encipher from master 
key operation. 
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The control vector, as generally shown in Fig. 10, can also include a field to designate whether the cryptographic 
key associated therewith is a single length key or a double length key. 

The following provides a more detailed description of the components and operations of the arrangement. 

Fig. 2 shows the major components of a crypto subsystem. The cryptographic subsystem consists of a Crypto 
s Facility (CF), Crypto Facility Access Program (CFAP), and Application Program (AP). Normally, the CF is implemented 
in hardware, inside a physically secure box. Depending upon the implementation, the CF, CFAP, and AP could all be in 
a physically secure box. 

The Cryptographic Facility 4 consists of: 

10 # Key Registers - The registers and their usages are described below: 

- Master Key Register 18 - The master key register is 128 bits wide, containing the master key. 

- New Master Key (NMK) register: - The new master key register is 128 bit wide, containing the new master key 
15 that is going to become the current master key. The New Master Key will become the current master key only after 

a special instruction, the SMK instruction is issued to load the value of new master key into the master key register. 

- Old Master Key Register - The old master key register is 1 28 bits wide, containing the master key that was replaced 
by the current master key. The master key update mechanism is such that the current master key becomes the old 

20 master key prior to the new master key becoming the current master key. 

- Key Part Register - The key part register is 128 bits wide, containing the value of a key part (component), or a 
complete key that is being installed via a key loading device such as a key pad or key board attached to the CF via 
an optional secured physical interface. 

25 

- Working Key Register(s) - For performance reasons, the system has working register(s), 128 bit wide each, to 
contain immediate working key(s) for fast accessed. For example, a key that is used to encrypt data is brought into 
the CF in encrypted form on the first use. It then is decrypted and the clear value can be stored in one of the working 
key registers. In subsequent uses to encrypt or decrypt the data, this clear key can be quickly accessed from a 

30 specific working key register, thus eliminating the repeated steps of decrypting the key prior to using it. 

- Program MDC Register (PMDC Reg) - The program MDC register is 64 bits wide, containing the MDC of the 
program to be loaded in the program memory inside the CF. 

35 - Dataset MDC register (DMDC Reg) - The dataset MDC register is 64 bits wide, containing the MDC of the datasets 

whose integrity is validated by CFAP. This normally is, at least, the key storage datasets. 

# Cryptographic instructions and control vector checking algorithms. - The instruction set and control vector checking 
algorithms are implemented in the secured cryptographic facility and are stored in the cryptographic instruction 

40 storage 1 0 which is a random access memory. They are executed in a microprocessor such as an Intel 80286 which 

can serve as the cryptographic processing unit 16. The control vector checking unit 14 can also be implemented in 
the cryptographic processing unit 16 or it can be implemented by a second microprocessor such as an Intel 80286 
serving as the control vector checking unit 14. 

45 # Program Memory and Processing Engine - The system can also employ a memory inside the CF to store user's 

programs and a processing engine to execute the programs. An example ot this is a program or macro for performing 
new algorithms for PIN verifications on new PIN formats. 

# Random Number Generator 26 - The random number generator is an algorithmic procedure for producing 64 bit 
so pseudo-random numbers. The algorithm itself is non-secret, but makes use of two 128 bit secret keys and a 64 bit 

non-secret incrementing counter. Although non-secret, the integrity and proper management of the counter are 
essential to security. 

The Crypto Facility (CF) is a secure implementation containing the Data Encryption Algorithm and storage for a 
55 small number of key and data parameters in the cryptographic instruction storage 10. It can be accessed only through 
inviolate interfaces (secure against intrusion, circumvention, and deception) which allow processing requests, key, and 
data parameters to be presented, and transformed output(s) to be received. 

The ANSI Data Encryption Algorithm (DEA) is a standard cryptographic algorithm for commercial data security 
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products. The DEA is a symmetric block cipher algorithm that uses a 56-bit secret key to encipher 64 bits of plain text 
to form 64 bits of cipher text. DEA keys are normally stored with 1 parity bit per byte, forming a 64-bit key. DEA forms 
the basis for the National Bureau of Standards approved Federal Data Encryption Standard, so it is also called DES. 
The cryptographic facility must resist probing by an insider adversary who has limited access to the cryptographic 
s hardware. "Limited" is measured in minutes or hours as opposed to days and weeks, and the adversary is constrained 
to a probing attack at the location where the system is installed, using limited electronic devices as opposed to a labo- 
ratory attack launched at a site under the control of the adversary using sophisticated electronic and mechanical equip- 
ment. 

The cryptographic facility must detect attempts at physical probing or intrusion. This may be accomplished using a 
10 variety of electro-mechanical sensing devices. 

The cryptographic facility must provide for the automatic zeroing of all internally stored clear keys. Such zeroing 
must be performed automatically whenever an attempted probing or intrusion has been detected. The cryptographic 
facility must also provide a manual capability to zero key storage via the front panel interface. 

The crypto facility contains one master key KM. All other keys can reside on master storage encrypted under a key 
is formed by Exclusive ORing the master key with a valid control vector. Refer to U.S. Patent 4,386,234 entitled "Crypto- 
graphic Communications and File Security Using Germinals" by Ehrsam, et al., assigned to IBM Corporation, and in- 
corporated herein by reference, for a description of an example Cryptographic Facility. 

The CFAP is the programming interface between the CF and the application program. Since users do not have 
direct access to the cryptographic facility, the CFAP is the programming interface through which the users can request 
20 the CF to perform specific operation. 

Associated with the CFAP is the Key Storage outside the CF where encrypted keys are stored. No clear keys are 
stored outside the CF. The Key Storage 22 is also referred to herein as the "Cryptographic Key Data Set" (CKDS). 

# The CFAP typically consists of the following: 

25 - Key Storage Manager to manage keys stored in the key storage mentioned above. 

CFAP Macros through which users access to the CF to perform cryptographic functions. 

Application programs include user's application programs, some utilities such as a key installation utility, and com- 
30 munication programs such as IBM VTAM. 

User's application programs consist of statements that will invoke certain CFAP macros to perform a specific task. 
As mentioned, the CFAP is the only interface through which application programs can request CF to execute a crypto- 
graphic operation. For example, a user might want to encipher a file prior to shipping it to another node on the network. 
His application program might have one statement that calls a CFAP macro to generate a key, and another statement 
35 that invokes another CFAP macro to encipher the data of the file with the given key. 

Another example of a user's application program is one that allows the manual installation of keys on the system, 
similar to the installation program mentioned above. 

Fig. 3 shows the use of control vectors for the key distribution between various applications in a multi-system com- 
munications environment. Note that for compatibility purposes some keys must be distributed without control vectors. 
40 # Notation - The following notation is used herein: 



ECB 


Electronic code book 


CBC 


Cipher block chaining 


KM 


128 bit Master key 


KEK 


1 28 bit Key encrypting key 


K 


64 bit key 


*K 


128 bit key 


HK 


64 or 128 bit key 


KD 


64 bit data encrypting key 


KK 


64 bit Key encrypting key 


*KK 


1 28 bit Key encrypting key 


KKo 


offset 64 bit Key encrypting key 


*KKo 


offset 1 28 bit Key encrypting key 


(*)KKo 


offset 64 or 1 28 bit Key encrypting key 


*KKNI 


128 bit partial notarising Key encrypting key 


*KN 


128 bit notarising key, equivalent to *KKNIo 


cx 


64 bit control vector 


CxL 


64 bit left control vector 
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CxR 


64 bit right control vector 


XOR or xor 


exclusive or operation 


or 


logical or operation 


X'O' 


Hex notation 


11 


concatenation operation 


[xj 


optional parameter x 


not = 


not equal 


E or e 


single encryption 


D ord 


single decryption 


EDE or ede 


triple encryption 


DED or ded 


triple decryption 


# Equations 





The function of each instruction is mathematically denoted in the form: 
11, 12, (3, 14,... —01, 02, 03,... where 11, 12, 13,... are the inputs to the function and 01, 02, 03,... are the outputs 
from the function. 



KM.Cx 



(KML XOR Cx) 11 (KMR XOR Cx) = KMY 11 KMX 
where, 



KML = 
KMR - 
KMY = 
KMX = 



Left 64 bits of the master key KM, 
right 64 bits of the master key KM, 
KML XOR Cx 
KMR XOR Cx 



e'KM.Cx(key) e*KM.Cx(key) = eKMY(dKMX(eKMY(key))) 

where, 



KMY = 
KMX = 
key = 



KML XOR Cx 
KMR XOR Cx 
64 bit key 



e*KEKn.Cx(key) e*KEKn.Cx(key) = eKEKY(dKEKX(eKEKY(key))) 
where, 



KEKY = 
KEKX = 
key = 



KEKnL XOR CxL 
KEKnR XOR CxR 
64 bit key 



e*KM.CxL(KEKnL) 



e*KM.CxL(KEKL) = eKMY)dKMX(eKMY(KEKnL))) 
where, 



KEKL = 
KMY = 
KMX = 



left 64 bits of KEK 
KML XOR CxL 
KMR XOR CxL 



e*KM.CxR(KEKnR) e*KM.CxR(KEKR) = eKMY(dKMX(eKMY(KEKnR))) 
where, 



KEKR = 
KMY = 
KMX = 



right 64 bits of KEK 
KML XOR CxR 
KMR XOR CxR 



e*KEKo(key) e*KEKo(key) = eKEKLo(dKEKRo(eKEKLo(key) 

where, 



KEKLo : 



KEKL XOR cntr 
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KEKRo = KEKR XOR cntr 

cntr = implicit 64-bit key-message counter for KEK 

key = 64 bit key 

s # Cryptographic Separation of Keys 

Keys are separated cryptograph ically according to key type and key usage attributes. 

1 . The architecture guarantees that cryptographic keys can be used only in the way or ways prescribed and intended. 

10 

2. Internal Versus On-The-Link Separation. Internally (i.e., within the cryptographic facility), keys are separated via 
control vectors or other appropriate/equivalent mechanism. On the link, keys are separated using control vectors. 

3. Hardware Versus Software Enforcement. Certain cryptographic separation is implemented in hardware; other 
'5 cryptographic separation can be implemented via software. 

4. Control vector key types and compatibility-mode key types. In order that the compatibility-mode key types will 
not diminish the security, certain rules governing generation, distribution, and usage of these two classes of key 
types is imposed. 

20 

5. A list of required key separations provided by the invention is listed below: 

a) Data Privacy. ENCIPHER from DECIPHER, allows public key protocols such as mailbox, ballot and pass on. 

b) Data MAC. MACGEN from MACVER, allows for non-repudiation (equivalent of electronic signature). 

25 c) Data XL ATE. Allows a secure translate channel to be established, where intermediate devices cannot decrypt 

encrypted data. 

d) Data COMPAT. Allows compatibility mode without weakening security of other data keys. 

e) Data ANSI. Allows ANSI X9. 1 7 key management to be coexist with non-ANSI X9. 1 7 key management without 
loss of security to either approach. 

30 f) Key Encrypting Keys. KEK Sender from KEK Receiver. 

g) PIN Keys. PIN Generating Key from PIN Encrypting Key. 

The following notation is used for Figs. 4 through 9: 

35 # Notation: 



Near each line leaving a box is a separation letter and a priority number. The separation letter will correspond with 
descriptions below. The range of priority numbers (1 through 4) should be interpreted as follows: 

40 1. Absolute necessity 

2. Strongly recommended 

3. Recommended 

4. Desirable 

45 # Fundamental Key Separation 

Fig. 4 illustrates the fundamental cryptographic key separation. An explanation of the separation is given below: 

1 . A. Data Keys : KEKs and PIN keys - If KDs (Data Keys) are not separated from KEKs and PIN keys, then Decipher 
50 data function used with data keys could be misused to decipher KEKs and PINs. 

2. B. Key Encrypting Keys : PIN keys - If KEKs (Key Encrypting Keys) are not separated from PIN Keys it would be 
possible for an outsider to wiretap an encrypted PIN block and replay it in place of an encrypted KD. Ahead of time, 
an insider accomplice could replace the encrypted stored KEK with the encrypted store PIN Key in the receiving 

55 node's cryptographic key data set. The PIN block would be then recovered and used as a data key at the receiving 

node. Subsequently, data that would be encrypted under this PIN block used as a data key would be much easier 
to subject to a key exhaustion attack as the variability of PINs (normally four to six decimal digits) is much less than 
that of a random 56 bit data key. 
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# Data Keys Separation 

Fig. 5 shows the flow chart of the Data keys separation. The justifications for the separation are given below. 

5 1. 

A - Authentication : Privacy - An insider who can collect plain and corresponding ciphertext encrypted with an 
MAC key can perpetrate an attack against the MAC procedure. For example, it would be possible to construct 
fraudulent messages and MACs that would be authenticated and accepted by the MAC algorithm. Thus, the 
10 data keys used for encryption/decryption should not be used for authentication of data. On the link, if an inter- 

cepted data key can be substituted for a MAC key, the transmitted ciphertext (under that data key) would be 
used to construct a fraudulent message and MAC. 

B. Xlate Ciphertext : Privacy - By definition, Xlate Ciphertext implies the use of a pair of data keys KD1 and 
15 KD2, where ciphertext encrypted under KD1 is decrypted under KD1 and then re-encrypted under KD2 without 

exposing the data to the calling application program. Otherwise, Xlate Ciphertext could be performed using the 
existing Decipher and Encipher functions. 

C - ANSI : all others - ANSI keys have their own protocol for key distribution and an additional possible usage 
20 referred to as ANSI COMBINE KEYS. These differences mandate a separate pool for all ANSI keys. 

D - Data compatibility : All others - Data Compatibility keys exist due to requirements to be compatible with 
previous systems such as IBM CUSP/3848, IBM PCF, and IBM 4700. As the enforced internal separation in 
these systems does not extend to the level of separating MAC from Privacy keys, these keys need to be dis- 
25 tinguished from the CV keys which support such an improved level of separation. 

2. B - MACGEN : MACVER - Provides an audit trail to -prove- who originated a message and MAC (called non-repu- 
diation). This method is no more secure than the CF, and assumes a mutual trust in the integrity and secrecy of 
keys stored in the CF. 

30 

3. C - Encipher : Decipher - Provides true separation of the encipher and decipher functions, thus permitting data 
to be enciphered under a data key without exposing the right to decipher under that same data key. For example, 
an encipher only data key could be used in a Vote and pass on' balloting scheme. A decipher only data key could 
be used in an environment where a user is authorised to read but not write some data. 

35 

# Pin Keys Separation 

Fig. 6 shows the flow chart of the Pin keys separation. The justifications for the separation are given below; 

^o 1 . A - PIN Generating Keys : PIN Encrypting Keys - An insider who could cause a PIN block to be forced equal to 

a valid ID value and then encrypted under a PIN generating key instead of a PIN encrypting key, could expose PINs. 

2. B - Generate PIN function : Encipher PIN function - During PIN generation, the Encipher PIN attribute allows 
separation of PIN Generating keys that allow clear PINs to be generated from those that always must output 

45 encrypted PINs. 

3. C - Create PIN Block & Generate PIN : Reformat PIN, Verify PIN & Xlate PIN - Permits the PIN encrypting key 
to be used with routine PIN processing functions like Reformat PIN, Verify PIN and Xlate PIN without allowing PIN 
keys to be used to create or otherwise "introduce" PINs into the network at electronic speeds. This would prevent 

50 dictionaries of plain and encrypted PINs to be collected at electronic speeds, which would be useful in attacking 

and recovering PINs without directly deciphering them. Tight control needs to be enforced over where and when 
and under what conditions PINs may be introduced into the system. 

4. D - Create PIN Block : Generate PIN - Greater control can be exercised over the introduction of PINs into the 
55 network. A node with a requirement to create PIN blocks need not necessarily have a right or need to generate PINs. 

5. E - Reformat PIN and Verify PIN : Xlate PIN - Greater control can be exercised over the PIN processing functions 
in the network. A node with a need and right to translate PINs does not necessarily have a right or need to reformat 
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a PIN or verify a PIN. The later two functions might be used in combination to exhaust PINs via an internal attack, 
whereas the Xlate PIN function could be used by some nodes without giving away full processing capabilities. 

# Key Encrypting Keys Separation 

5 

Fig. 7 shows the flow chart of the Key encrypting keys separation. The justifications for the separation are given 
below: 

1. A - Notarisation : non-Notarisation - An insider might be able to cause a key intended for use with offset to be 
10 used without offset/notarisation, such that the variant on the key is equal to an old offset counter value. Conversely, 

an insider might be able to cause a key intended for use only for non-offset / authorisation to be used with an offset 
process, such that the offset on the key is equal to a variant not intended to be created or generated via a privileged 
mode in the crypto facility or by an entry in the authorised variant table. 

15 2. B - CV KEKs : non-CV KEKs - Cryptographic operations in support of other non-CV network nodes, executed by 

a CV cryptographic facility, must not allow CV network node security to be weakened or diminished. For example, 
a CV system must support the import of both privacy and authentication (MAC) keys from a non-CV IBM 4700 or 
IBM 3848 system. In all cases, these data keys are received under variant 0 of the shared cross domain key. If the 
shared cross domain keys of these non-CV systems are not separated cryptographically from the CV system cross 

20 domain keys, then it would be possible to import a CV system data key intended for one purpose (specified by 

variant 0 of the cross domain key) and translate it for another purpose (specified by some other variants). 

3. C - KEK Sender : KEK Receiver - Maintain the same uni-directionality feature on cross domain keys as is present 
in the current IBM 3848/CUSP and IBM PCF. Also provides better control in preventing the unauthorised creation 

25 of bi-directional KEK's. 

4. D - GENKEYSET/XLATE : RFMK/GENKE YSET/XLATE - Permit KEK's in support of the GENKEYSETand LXATE 
for shipment of data keys without necessarily allowing the export of existing data keys stored under the master key 
(or variant of master key). Thus, data keys used by the CV system are not exposed for export unless this feature 

30 is needed or desired. 

5. E - GENKEYSET (Export only)/XU\TE : GENKEYSET (general use) - Permits a node to act as a Key Distribution 
Centre (KDC) or a Key Translation Centre (KTC) without the ability to use the generated data keys without the 
generating node. 

35 

6. F - RTMK : RFMK on IBM 3848/CUSP (and compatible system) - Supports uni-directionality on IBM 3848/CUSP 
and other systems that are compatible with C V systems. 

Fig. 8 shows a summary of the key separations and assigns a relative priority to them. Highest priority is 'V and 
40 lowest '4'. 

Fig. 9 summarises the separation flows. The leaves' on the tre-e indicate the cryptographic instructions that make 
use of the separate key types. 

Control Vectors 

45 

# Control Vectors Concept 

The control vector is a 64 bit non-secret cryptographic variable for controlling the usage of keys. Each key K defined 
to the cryptographic system has an associated control vector C, i.e., the key and control vector define a tuple (K, C). 

50 Each control vector specifies a CV TYPE, which broadly defines how the key may be used and the rules governing 

how that key may be communicated on the link. A key may be a data key, sender key encrypting key, receiver key 
encrypting key, PIN encrypting key, PIN generating key, Intermediate ICV, Key part or Token. Additional bits in the control 
vector specify exactly in which cryptographic instructions and parameter inputs the key may operate. Still other bits 
control the export of the key, i.e., whether the key can be exported or not. 

55 The control vector is coupled cryptographically to the key via a special encryption function. For example, when the 

K is stored in a Key Storage, K is encrypted under a key formed by Exclusive-ORing the control vector with the master 
key, i.e., K is stored as the tuple (eKM.C(K), C), where KM C denotes KM xor C. When K is transmitted on the link (from 
one device to another), a similar encrypted form is used. In this case, the master key KM is replaced by a key encrypting 
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key KEK, where KEK is a key shared between the sender and receiver. Thus, K is transmitted as the tuple (eKEK.C(K), 
C). The architecture does not require that the control vector be stored or transmitted with the key in situations where its 
value is defined implicitly from the context or can be reconstructed from available key-related information. 

Since the control vector (C) is tightly coupled to the key (K), via the encrypted form eKM.C(K) or eKEK.C(K), it is 

s apparent that K cannot be recovered from its encrypted form unless C is correctly specified. Thus, if the tuple (EKM.C 
(K), C) is provided as an input to a requested cryptographic instruction, the cryptographic facility will first check the 
supplied value of C to determine that the requested usage of the key is permitted. Only then will C be used to decrypt 
eKM.C(K) to recover the clear value of K internal to the cryptographic facility. If a false value C* is specified, the cryp- 
tographic facility may be fooled temporarily into accepting C*. but K will not be recovered properly. Thus, there is no 

10 opportunity for a user to recover the correct value of K unless the correct value of C is also specified. The cryptographic 
principle is thus the basis upon which the entire architecture is built; and additional security is provided as necessary 
and where appropriate. 

The control vector is a compact data structure for defining the usage attributes of a cryptographic key. The control 
vector is cryptograph ically coupled to the key via an encryption process. This process is such that the key can be de- 
is crypted properly only if the control vector is correctly specified. (Even a single bit change in the control vector will cause 
an entirely different key to be recovered.) 

# CV Checking 

20 The control vector is designed to minimise CV checking. Control vector usage bits are defined and structured so 

that each usage attribute, by itself, grants or denies a specific usage. Thus, the capability to encipher data via the 
Encipher Data instruction is controlled via a single "Encipher" bit within the control vector whose type/subtype is "da- 
ta/privacy". 

Thus, each usage attribute is defined independently from all other usage attributes. This guarantees a CV checking 
25 process such that each instruction checks only the usage attributes called for by the requested function. A design wherein 
usage attributes are enabled only when certain other attributes are enabled or disabled is specifically avoided, since 
this increases CV checking. Some cross checking of attributes among two or more control vectors is required, but is 
kept to a minimum. 

To facilitate and simplify CV checking, each cryptographic instruction, where necessary, is passed a "mode" param- 
30 eter declaring a specified use of the key or keys passed as parameters to the instruction. Thus, the CV checking process 
tests each control vector according to the specified "mode". This eliminates costly cross checking among control vector 
attributes to ensure consistency. 

The design also follows a principle that no cryptographic instruction generates a control vector. All control vectors 
are supplied to the cryptographic instructions as parameter inputs. 
35 Where possible, like usage attributes and field definitions are located at the same bit positions in the control vector, 

regardless of CV type. This facilitates CV checking. For example, the translate ciphertext instruction interrogates the 
same bit positions in the data/privacy and the data/xlate control vectors, even though the usage bits are "E" and P D P for 
the data/privacy CV and "XOUT" and "XIN" for the data/xlate CV, respectively. 

# CV Structure - In general, the control vector structure (including formats, field and bit assignments) has been 
40 defined to minimise and to facilitate CV checking, while at the same time providing cryptographic security. The CV 
structure, so to speak, is the variable with the greatest degree of freedom in the design process. 
The following design options have been employed in the control vector: 

1 . Vertical Separation. - The control vector has a "CV Type - field that provides vertical separation within the control 
45 vector structure, much like the separation provided by variants. Control vector types are defined along intuitive lines, 

following existing key terminology and key management. However, vertical separation is implemented only where 
necessary under the CA, thus ensuring architectural simplicity and ease of comprehension of the CV checking rules. 
By first defining broad classes of CV Main Types (e.g. Data Keys, Key Encrypting Keys, PIN Keys) and then further 
defining CV Subtypes and usage attributes within CV Type, the CV checking rules can be optimised much in the 
50 same way that a "divided and conquer" search can be employed more effectively than a brute force approach. 

2. Horizontal Separation. - The control vector is ideally suited as a data structure for recording the usage attributes 
to be associated with a key (or other cryptographic variable). Within the CA, this is accomplished by specifying a 
bit in the control vector for every cryptographic instruction (or key parameter within the instruction, if more than one 

55 key parameter may participate) where the key may be used as an input. A bit value of "1 " signifies that a usage of 

the key is "enabled" by the CF whereas a bit value of "0" signifies that a usage of the key is "disabled" by the CF. 
This form of control vector structuring is called horizontal separation. 
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3. Encoded Fields. - A field of two or more bits is sometimes encoded for reasons of security. An encoded field has 
the property that individual bits have no significance by themselves, but the bits together define a set of possible 
values. Encoded fields have the advantage that they define mutually exclusive events since the field can take on 
only one value at a time. Encoded fields have the potential disadvantage that CV checking is not always optimised 

5 from a performance standpoint. However, encoded fields are sometimes necessary to ensure that usage attributes 

cannot be mixed in inappropriate combinations that give rise to cryptographic attack or introduce some cryptographic 
weakness. 

4. Protection From Non-System Generated Keys. - The method for coupling the control vector and key is such that 
10 CV checking is unable to detect a system generated key (via KGEN or GKS) from a non-system generated key. For 

this reason, a "back-door 0 method exists within the architecture for generating a keys and control vectors. It consists 
of defining a control vector "of choice" and a random number which is then represented as a key encrypted in the 
manner described under the architecture using the selected control vector. (However, the method has no capability 
to control the key actually recovered within the cryptographic facility). The so-called "back-door 0 method of key 

is generation is primarily an annoyance, although in some cases cryptographic attacks would be possible if additional 

measures of defence were not taken in the architecture. It would be a simple matter to define an architecture that 
eliminates this "back-door" key generation (once and for all), but doing so would introduce additional unwarranted 
complexity and processing. A more practical approach is followed by the CA, vis., the "back-door" key generation 
problem is prevented only where necessary for security reasons. Thus, a good balance among security, complexity, 

20 and performance is achieved. Techniques toavoid cryptographic weaknesses introduced by the "back-door" method 

of key generation are these: 

a) Where necessary, conflicting usage attributes within a single control vector are split among two control vec- 
tors. The GKS instruction has checking that prevents so-called bad combinations of key pairs from being gen- 

25 erated. 

b) Where necessary, conflicting usage attributes within a single control vector are grouped into a single encoded 
field. 

c) As a last resort, extra redundancy is used so that the CF can validate its own system generated keys. 

30 5. Even Parity for Control Vectors. - Even parity is enforced on the control vector. This ensures that the Exclusive -OR 

of an odd parity key with the control vector will result in an internal key of odd parity. This, in turn, ensures compatibility 
with hardware that may check such internally derived keys for odd parity (if such checking is enforced). Saying it 
another way, the CA cannot ensure that hardware will not enforce this odd parity on internal keys. A control vector 
of 64 bits, numbered 0 through 63. The most significant bit is bit 0, by convention. Of the 64 bits, there are 8 parity bits. 

35 

6. Anti-Variant Bits. - This guarantees cryptographic separation between variants and control vectors, which may 
unavoidably be mixed in some implementations internal to a node. 

7. Avoid Onto Mappings. - The control vector design and the manipulation of the control vector via the cryptographic 
40 instruction set avoids instances where CV fields with multiple values are mapped into a single value. Some specific 

instances of such onto mappings are allowed (e.g., LCVA, RFMK, and RTMK instructions) where security is not 
jeopardised. 

# CFAP Control 

45 

Certain bits in the control vector are reserved for CFAP These bits can be used by CFAP for further key management 
control. These bits are not checked by the CF, but are entirely managed by CFAP. 

General Format for Control Vectors 

50 

Fig. 10 shows the general format for control vectors. The first row of of Fig. 10 shows the fields that are in common 
for most of the control vectors. They are briefly described as follows: (Further details can be found in subsequent sub- 
sections.) 

ss #CVType 

This field indicates the type of control vector, and is also the key type of the key to which this control vector is 
attached. The CV Type field consists of main-type and sub-type. 
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The main types of a control vector are: 

Data key - Data keys are used to encrypt/decrypt data, or to authenticate data. 
PIN key - PIN keys are used to encrypt PINs or to generate PINs. 
s - Key-encrypting key - Key-encrypting keys are used to encrypt keys. 

Key part - A key part is a part or a component of a key, having the same length as the key. For example, a key K 
may have two key parts Ka and Kb such that Ka XOR Kb = K. 

Intermediate ICV - An Intermediate ICV is used during MAC processing to encrypt the intermediate Output Chaining 
Value of a segment of data or message. This OCV is then fed into the next segment of the data and used as an 
10 ICV. This occurs when a message or data on which a MAC to be generated or verified is long and must be divided 

into shorter segments. 

Token - Tokens are variables used to protect the integrity of the data keys stored in the Data Key Dataset (a key 
storage for Data keys). They help prevent the access of data keys by unauthorised users. 

'5 The sub type differentiates the classes of keys of the same main type. For example, a key of main type data key 

can have the sub type of privacy (capable of doing encryption and decryption); or MAC (capable of doing data authen- 
tication); or XLATE Data (capable of translating ciphertext); etc. When no sub-type distinction is made, the keys are 
normally referred by the main type (e.g., Data key, PIN key, etc.) 

20 # Export Control 

This field indicates how the export of the key associated to this control vector is controlled, and whether the key is 
allowed to be exported. 

2S # CF Enforced Usage 

This field indicates for what CA functions the key can be used, and how it is used. For example, a data privacy key 
may have the usage attributes E = 1 and D = 1 , which indicate that the key can be used in the Encipher and Decipher 
function to encrypt and decrypt the data, respectively. 

30 

# AV (Anti-Variant) 

This field differentiates any valid control vector from the 64 predefined variants that are used in variant-based crypto 
systems. Since all 8 bytes of the any variant of the 64 predefined variants are the same, setting the value of the AV field 
35 such that at least two bytes of the control vector are not the same will differentiate a valid control vector from a predefined 
variant. 

# Software Bits 

40 This field represents control vector bits that are controlled/managed entirely by CFAP; The software field is not 

checked/enforced by the hardware (CF). When no control vector exists, CFAP builds a control vector from information 
supplied to CFAP (normally via parameter in a macro). When a control vector already exists, CFAP will check the control 
vector (Including the software field) to determine whether the key is allowed to operate in the manner specified/requested. 
The hardware (CF), unlike software (CFAP), checks only those bits associated with a CA instruction, other usage bits 

45 are not checked). 

# Extension 

This field indicates whether the control vector is a 64 bit control vector or an extended control vector of 128 bits. In 
50 the current CA, all the control vectors have 64 bits in length. This field is defined now to ease the expanding of the control 
vector in the future when the number of bits required to specify the control vector exceeds the b4 bit length. 

# Reserved Bits 

55 This field is reserved for the system for future use. 
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# Parity Vector 

Every parity bit is the even parity of the preceding 7 bits of the byte. 

For key-encrypting key control vectors, besides the common fields listed above, there are two additional fields, KEY 
5 FORM and LINK CONTROL. 

# Key Form 

This field indicates the length of the key (single or double length) and whether the key half associated with the 
10 control vector key is the right or left half of the key. Note that for a single length key, the right half is the same as the left 
half and is the key itself. 

# Link Control 

15 This field indicates how the key-encrypting key associated to this control vector is used to transmit other keys on 

the link, and what type of system (e.g., CV system or non-CV system) can keys be shipped to or received from , under 
this key-encrypting key. 

Note that the descriptions in the second row and the third row in the genera! figure and other referenced figures in 
this section are not part of the control vector. They are put there to give information on the fields of the control vector 
20 as follows: 

The second row indicates the bit length of the fields. The abbreviation 'b' stands for 'bit'. For example, 1 b stands for 
1 bit, 3b stands for 3 bits, etc. 

25 - The third row indicates whether the field is checked by hardware (CF) or software (CFAP). 

Control Vector Format for Data Key 

Data keys are divided into the following subtypes: 

30 

Data Compatibility Key. This is the data key that would be used to maintain compatibility with existing systems such 
as IBM 3848/CUSP or IBM 4700 FCS. Since these existing systems do not have the cryptographic separation 
between privacy and authentication, this key can be used to perform any or all of the following functions: encipher, 
decipher, generate MACs and verify MACs. This control vector can be removed (i.e., substituted by CV = 0 
35 on-the-link) when it is exported to other systems (via the RFMK instruction), whereas the control vectors for all other 

data keys except ANSI data keys cannot be removed. 
Privacy Key. This is the key used for enciphering and/or deciphering only. 

MAC Key. This is the key used for the purpose of data authentication only. That is, it can only be used to generate 
MACs and/or verify MACs. 

40 - Data Translation Key (Data XLT Key). This is the key used in the translation of ciphertext. 

ANSI Key. This is the key that is used in ANSI applications. It can be used to encipher and decipher data or to 
generate and verify MACs. It can also be combined with another ANSI key to form an ANSI MAC key (i.e., a Data 
ANSI key with generate MAC/verify MAC capability). This control vector can be removed when exported to other 
systems (i.e., substituted by CV = 0 on-the-link) via the ARFMK instruction, whereas the control vectors for all other 

45 data keys except compatibility keys cannot be removed. 

Depending on the CV subtype of the control vector, the bits in the USAGE field have specific meaning to be described 
shortly. 

50 Control Vector for Privacy Keys 

Refer to Fig. 11 . The following is a detailed description of each field and subfield of this figure. 

# CV Type - for privacy key (main type = "DATA KEY", subtype = "PRIVACY"). 

55 

# Export Control (controls exporting of this key): This field occupies 1 bit: 

- EXPORT CONTROL = 1 : This key can be exported by RFMK. Also, the RFMK, RTMK and LCVA instruction can 
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reset this bit to 0. 

- EXPORT CONTROL - 0: This key cannot be exported by RFMK. Also, it cannot be changed to 1 by any instruction. 
5 As an example, suppose node X generates a key K and control vector C and sends them to node Y. 

# Usage 

# E 

10 

- E = 1 : This key can be used in the ENCIPHER instruction to encrypt the data. 

- E = 0: This key cannot be used in the ENCIPHER instruction to encrypt the data. 
15 * d 

- D = 1 : this key can be used in the DECIPHER instruction to decrypt the data. 

- D = 0: This key cannot be used in the DECIPHER instruction to decrypt the data. 

20 

# AV (Anti-Variant) 

This field occupies two bits, used to differentiate the control vector from 64 predefined variants that are used in 
variant-based crypto systems. Since all 8 bytes of the any variant of the 64 predefined variants are the same, setting 
25 the value of the AV field such that at least two bytes of the control vector are not the same will differentiate a valid control 
vector from a predefined variant. 

# Software bits 

30 This field occupies 12 bits. 

# CV Version - This field is 6 bits long and is used by CFAP to distinguish the current control vector definition from 
future definitions. 

35 * Software = Enforced Usage - See also the CFAP section. 

- CVDPIM (Control Vector Data Privacy ICV Mandatory) 

- CVDPCU (Control Vector Data Privacy CUsp) 

40 

- CVDP47 (Control Vector Data Privacy 4700) 

- CVDPM8 (Control Vector Data Privacy Multiple of 8) 

45 # Extension - This field indicates whether the control vector is a 64 bit control vector or an extended control vector 

of more than 64 bits. 

# Reserved bits - This field is reserved for the system for future use. 

50 # Parity - This field consists of the last bit of every byte of the control vector. The parity bit of each byte is set to 

achieve even parity for the byte. 

Control Vector for MAC keys 

55 Refer to Fig. 1 3. The following is a detailed description of each field and subfield of this figure. 

# CV Type - CV TYPE for MAC key (main type = :DATA KEY", sub type = "MAC"). 
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# Export Control (controls exporting of this key) - Same description as that of Privacy keys. 

# Usage 
s * MG 

- MG = 1 : This key is permitted to be used in the GMAC instruction to generate MACs on data. 

- MG = 0: This key is not permitted to be used in the GMAC instruction to generate MACs on data. 

10 

*MV 

- MV = 1 : This key is permitted to be used in the VMAC instruction to verify MACs on data. 

15 - MV = 0: This key is not permitted to be used in the VMAC instruction to verify MACs on data. 

# AV (Anti-Variant) - Same description as that of Privacy keys. 

# Software bits - This field occupies 12 bits. 

20 

# CV version - Same description 

# Software-Enforced Usage - See also the CFAP section 
25 - CVDML4 (Control Vector Data MACLEN = 4) 

- CVDM99 (Control Vector Data MAC MODE = ANSI X 9.9) 

- CVDM19 (Control Vector Data MAC MODE = ANSI X 9.19) 

30 

- CVDM00 (Control Vector Data MAC MODE = IBM 4700) 

- CVDM30 (Control Vector Data MAC MODE = IBM 4730) 
35 # Extension - Same description as that of Privacy keys. 

# Reserved bits - Same description as that of Privacy keys. 

# Parity bits - Same description as that of Privacy Keys. 

40 

Control Vector for Data Compatibility Keys 

Refer to Fig. 14. The following is a detailed description of each field and subfield of this figure. 
45 # CV Type - CV TYPE = for data compatibility key (main type = "DATA KEY", sub type = "COMPATIBILITY" 

# Export Control - Same description as that of Privacy keys. 

# Usage 

50 

# E 

- E = 1 : This key can be used in the ENCIPHER instruction to encrypt the data. 

55 - E = 0: This key cannot be used in the ENCIPHER instruction to encrypt the data. 

# D 
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- D = 1 : This key can be used in the DECIPHER instruction to decrypt the data. 

- D = 0: This key cannot be used in the DECIPHER instruction to decrypt the data. 
5 * MG 

- MG = 1 : This key can be used in the GMAC instruction to generate MACs on data. 

- MG = 0: This key cannot be used in the GMAC instruction to generate MACs on data. 

w 

# MV 

- MV = 1 : This key can be used in the VMAC instruction to verify MACs on data. 

is - MV = 0: This key cannot be used in the VMAC instruction to verify MACs on data. 

# AV (Ant i- Variant) - Same description as that of Privacy keys. 

# Software bits - This field occupies 12 bits. 

20 

# CV Version - Same description as that of Privacy keys. 

# Software - Enforced Usage 

25 # Extension - Same description as that of Privacy keys. 

# Reserved bits - Same description as that of Privacy keys. 

# Parity bits - Same description as that of Privacy keys. 

30 

Control Vector for Data XL ATE key 

Refer to Fig. 15. The following is a detailed description of each field and subfield of this figure. 
35 # CV Type - CV Type for data XLATE key (main type = "DATA KEY", sub type - "XLATE") 

# Export Control (controls exporting of this key) - Same description as that of Privacy keys. 

# Usage 

40 

# XDout 

- XDout = 1 : This key is permitted to be used as the output data key in the TRANSLATE CIPHERTEXT instruction. 
45 . XDout = 0: This key is not permitted to be used as the output data key in the TRANSLATE CIPHERTEXT instruction. 

*XDin 

- XDin-1 : This key is permitted to be used as the input data key in the TRANSLATE CIPHERTEXT instruction. 

50 

- XDin = 0: This key is not permitted to be used as the input data key in the TRANSLATE CIPHERTEXT instruction. 

# AV (Ant i- Variant) - Same description as that of Privacy keys. 
55 # Software Bits - This field occupies 1 2 bits 

# CV Version 
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* Software- Enforced Usage - None. 

# Extension - Same description as that of Privacy keys. 

5 # Reserved Bits - Same description as that of Privacy keys. 

# Parity Bits - Same description as that of Privacy keys. 
Control Vector for ANSI Data Keys 

10 

Refer to Fig. 16. The following is a detailed description of each field and subfield of this figure. 

# CV Type - CV Type for data ANSI key (main type = 'DATA KEY", sub type = "ANSI") 
is # Export control - Same description as that of Privacy keys. 

# Usage 
*E 

20 

- E = 1 : This key can be used in the ENCIPHER instruction to encrypt the data. 

- E = 0: This key cannot be used in the ENCIPHER instruction to encrypt the data. 
25 * d 

- D = 1: This key can be used in the DECIPHER instruction to decrypt the data. 

- D = 0: This key cannot be used in the DECIPHER instruction to decrypt the data. 

30 

* MG 

- MG = 1 : This key can be used in the GMAC instruction to generate MACs on data. 

36 - MG = 0: This key cannot be used in the GMAC instruction to generate MACs on data. 

* MV 

- MV-1 : This key can be used in the VMAC instruction to verify MAC on data. 

40 

- MV = 0: This key cannot be used in the VMAC instruction to verify MAC on data. 

* ACMB - This bit indicates whether the data key can be XORed with another data key having the ACOMBKD 
attribute. The XORing process is done by the ACOMBKD instruction, as will be described in section "ANSI Combine 

46 KDs (ACOMBKD). B The resulting key is used to verify and generate MACs for the messages communicated via the 

ANSI X9.17 protocol. 

- ACMB = 1 : This data key can be combined in the ACMB instruction. 

so - ACMB = 0: This data key cannot be combined in the ACMB instruction. 

# AV (Anti-Variant) - Same description as that of Privacy keys. 

# Software Bits 

ss 

* CV Version - Same description as that of Privacy keys. 

* Software- Enforced Usage - None. 
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# Extension - Same description as that of Privacy keys. 

# Reserved Bits - Same description as that of Privacy keys. 
5 # Parity Bits - Same description as that of Privacy Keys. 

Control Vector Format for PIN Keys 

Pin keys are divided into the following subtypes: 

w 

PIN -encrypting keys (PEKs) - These are the keys that are used to encrypt PINs. 

PIN-generating keys (PGKs) - These are the keys that are used to generate PINs. In some cases, the PGKs are 
also called PIN validating keys since they are used to validate/verify PINs. 

15 Control Vector for PIN-Encrypting Keys 

Refer to Fig. 17. The following is a detailed description of each field and subfield of this figure. 

# CV Type - CV TYPE for PIN-encrypting key (PEK) (maintype = "PIN key", subtype = n PIN-encrypting key" 

20 

# Export Control - Same description as that of Privacy keys. 

# Usage 

25 * Create PI NBLK 

- CREATE PINBLK = 1 : This key is allowed to encipher the PIN Block in the CREATE PIN BLOCK instruction. 

- CREATE PINBLK = 0: This key is not allowed to encipher the PIN Block in teh CREATE PIN BLOCK instruction. 

30 

*GINPIN 

- GENPIN = 1: This key is allowed to encrypt the input customer PIN (CPIN) in the GENERATE PIN instruction. 
35 - GENPIN = 0: This key is not allowed to encrypt the input customer PIN (CPIN) in the GENERATE PIN instruction. 

# VERPIN 

- VERPIN = 1 : This key is allowed to encrypt the PIN input to the VERIFY PIN instruction. 

40 

- VERPIN = 0: This key is not allowed to encrypt the PIN input to the VERIFY PIN instruction. 
*XPIN in 

45 - XPIN in = 1 : This key is allowed to encrypt the input PIN in the TRANSLATE PIN instruction. 

- XPIN in = 0: This key is not allowed to encrypt the input PIN in the TRANSLATE PIN instruction. 

# XPIN out 

so 

- XPIN out = 1 : This key is allowed to encrypt the output PIN in the TRANSLATE PIN instruction. 

- XPIN out = 0: This key is not allowed to encrypt the output PIN in the TRANSLATE PIN instruction. 
55 # AV (Anti- Variant) - Same description as that of Privacy keys. 

# Software Bits - This field occupies 12 bits. 
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* CV Version - Same description as that of Privacy keys. 

* Software-Enforced Usage - None. 

5 # Extension - Same descriptions that of Privacy keys. 

* Reserved Bits - Same description as that of Privacy keys. 

* Parity Bits - Same description as that of Privacy keys. 

10 

Control Vector for PIN-Generating Keys 

Refer to Fig. 18. The following is a detailed description of each field and subfield of this figure: 
is # CV TYPE - CV TYPE for PIN-generating keys (maintype = "PIN key", subtype = "PIN-generating key 0 

* Export Control - Same description as that of Privacy keys. 

* Usage 

20 

* GENPIN - This field occupies 2 bits, indicating the conditions under which the key is allowed to generate PINs or 
PIN Offsets in the GENERATE PIN instruction. 

- GENPIN = B'OO': not allowed to generate PINs or PIN offsets. 

25 

- GENPIN = B'OV: allowed to generate a clear PIN or clear PIN offset. 

- GENPIN = B'10*: allowed to generated an encrypted PIN or encrypted PIN offset. 

30 - GENPIN = B'1V: allowed to generate a clear or encrypted PIN, or a clear or encrypted PIN offset. 

* GPIN - This bit indicates whether the customer selected PIN(CPIN) can be input to the GENPIN instruction in the 
form of a clear PIN or an encrypted PIN. 

35 - GPIN = 0: Clear or encrypted PIN is allowed. 

- GPIN = 1: Only encrypted PIN is allowed. 

* VERPIN - This bit indicates whether the key can be used as a PIN-validating key to verify PINs in the VERIFY 
40 pin instruction. 

- VERPIN = 1 : Allowed to be used to verify PINs. 

- VERPIN = 0: Not allowed to be used to verify PINs. 

45 

* VPIN - This bit indicates whether the PIN to be verified in the VERIFY PIN instruction can be input to the instruction 
in the form of a clear PIN or an encrypted PIN. 

- VPIN = 0: Clear or encrypted PIN is allowed. 

50 

- VPIN = 1 : Only encrypted PIN is allowed. 

* AV (Anti-Variant) - Same description as that of Privacy keys. This field occupies 12 bits. 
55 # Software Bits 

* CV VERSION - Same description as that of privacy keys. 
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# Software-Enforced Usage - None. 

# Extension - Same description as that of Privacy keys. 

5 # Reserved Bits - Same description as that of Privacy keys. 

# Parity bits - Same description as that of Privacy keys. 
Control Vector Format for Key-Encrypting Keys 

w 

Key-encrypting keys are divided into the following sub-types: 

KEK (Key-encrypting key) sender - This type of KEK is used to send or export keys. 
KEK receiver - This type of KEK is used to receive or import keys. 
is - KEK ANSI - This type of KEK is ANSI X9.17 key management environment. 

Control Vector Format for KEK Sender 

Refer to Fig. 19. The following is a detailed description of each field and subfield of this figure. 

20 

# CV Type - CV TYPE for KEK sender (maintype = "Key encrypting key (KEK)", subtype = "Sender" 

# Export Control - Same description as that of Privacy keys. 
25 # usage 

# GKS - This field occupies 3 bits, indicating whether the key can participate as an exporter key in one or more of 
the following nodes of the GKS instruction: Import-Export, Operational-Export and Export-Export. 

30 - Bit 0: Import-Export mode. - This is the mode where the GKS instruction generates 2 copies of the key, one copy, 

referred to as the import copy, is in a form ready to be later imported by the generating node; the other copy, referred 
to as the export copy, is in a form ready to be shipped to another node. 

-- Bit 0 = 1 : This key is allowed to ship the export copy of the key generated in the IM-EX (Import-Export) mode. 
35 - Bit 0 = 0: This key is not allowed to ship the export copy of the key generated in the Im-Ex (Import-Export) mode. 

- Bit 1 : Operational-Export mode. - This is the mode where the GKS instruction generates 2 copies of the key, one 
copy of the key is for local use (Operational copy) and the other copy is in a form ready to be shipped to another 
node (Export copy). 

40 

-- Bit 1 = 1 : This key is allowed to ship the export copy of the key generated in the Op-Ex (Operational-Export) 
mode. 

-- Bit 1 = 0: This key is not allowed to ship the export copy of the key generated in the Op-Ex (Operational-Export) 
mode. 

45 

- Bit 2: Export- Export mode. - This is the mode where the GKS instruction generates 2 copies of the key, each copy 
is in a form ready to be shipped to a different node. 

Bit 2 = 1 : This key is allowed to ship one of the export copies of the key generated in the Ex-Ex (Export-Export) 
50 mode. The copy to be shipped is specified by a parameter in the GKS instruction. 

- Bit 2 = 0: This key is not allowed to ship keys generated in the export-export mode. 

# RFMK - This field occupies one bit. 

55 - RFMK = 1 : This key is allowed to export keys to other nodes via the RFMK instruction. 

- RFMK = 0: This key is not allowed to export keys to other nodes via the RFMK instruction. 
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# XLTKEY out 

- XLTKEY out = 1 : This key can be used as the KEK in the TRANSLAT KEY instruction to re-encrypt a key that was 
previously encrypted under a different key. 

5 

- XLTKEY out = 1 : This key cannot be used as the KEK in the TRANSLAT KEY instruction to re-encrypt a key that 
was previously encrypted under a different key. 

# Key Form - This field occupies two bits, indicating whether the KEK is a short key (i.e., single length) or a long 
10 key (i.e., double length) and whether it is the right half or the left half of the key. 

# Link Control - This field occupies two bits, indicating how this KEK is used to send or receive keys on the link. 

- LINK CONTROL = B'00': Not applicable. 

15 

- LINK CONTROL = B'OV: CV only. That is, a key K being sent must be encrypted under a key formed by the XOR 
of this KEK and the control vector associated to the key K. Obviously, this type of link environment or channel is 
appropriate for the exchanges of keys when both the communicating nodes are the nodes that implement CA. 

20 - LINK CONTROL = B'1 0': CV = 0 only. That is, a key K being sent is encrypted under this KEK rather than with the 

key formed by the KEK XORed with a non-zero control vector. This type of channel is appropriate when either the 
receiving node, or the sending node is a non-CV node. 

- LINK CONTROL = B'1 V: CV or CV = 0. That is, the key K being sent may be encrypted under the KEK only, or 
25 may be encrypted under a key formed by the XORing of the KEK to the control vector associated with the key K. 

This type of channel is appropriate for a CA node that, besides applications running in a CA environment, it has 
some existing applications that do not recognise control vectors. For existing applications that do not recognise 
control vectors, the node exports keys encrypted under the encryption of KEK only. For applications running in a 
CA environment, the node exports keys encrypted under the key formed by KEK XORed with the control vector 
30 associated to the key being shipped 

The Key management section describes in more details the use of these types of channels to exchange keys. 

# AV (Ant i- Variant) - Same description as that of Privacy keys. 

35 

# Software Bits - This field occupies 12 bits. 

# CV Version - Same description as that of Privacy keys. 
40 # Software- Enforced Usage - See also the CFAP section. 

- CVKSKD (Control Vector KEK Sender - Send Data Key) 

- CVKSKP (Control Vector KEK Sender - Send PIN Key) 

45 

- CVKSKK (Control Vector KEK Sender - Send KEK) 

# Extension - Same description as that of Privacy keys. 

so # Reserved Bits - Same description as that of Privacy keys. 

# Parity Bits - Same description as that of Privacy keys. 
Control Vector Format for KEK Receiver 

55 

Refer to Fig. 20. The following is a detailed description of each field and subfield of this figure. 

# CV Type - CV TYPE for KEK receiver (maintype = "Key encrypting key (KEK) n , subtype = Receiver) 
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# Export Control - Same description as that of Privacy keys. 

# Usage 

s * GKS - This field occupies 2 bits, indicating whether the key can participate as an exporter key in one or more of 

the following nodes of the GKS instruction: Import-Export and Ope rational -Import. 

- Bit 0: Import-Export mode. - This is the mode where the. GKS instruction generates 2 copies of the key, one copy, 
referred here as the import copy, is in the form ready to be later imported by the generating node; the other copy, 

10 referred here as the export copy, is in the form ready to be shipped to another node. 

- Bit 0 = 1 : This key is allowed to encrypt the import copy of the key generated in the Im-Ex (Import- Export) mode. 

- Bit 0 = 0: This key is not allowed to encrypt the import copy of the key generated in the Im-Ex (Import-Export) mode. 

15 

- Bit 1 : Operational-import mode. - This is the mode where the GKS instruction generates 2 copies of the key, one 
copy of the key is for local use (operational copy) and the other copy is in the form ready to be imported to the 
generating node (import copy). 

20 - Bit 1 = 1 : This key is allowed to encrypt the import copy of the key generated in the Op-Imp (Operational-Import) 

mode. 

- Bit 1 = 0: This key is not allowed to encrypt the import copy of the key generated in the Op-Imp (Operation- 
al-Import) mode. 

25 * RTMK - This field occupies one bit. 

- RTMK = 1 : This key is allowed to receive keys via the RTMK instruction. 

- RTMK = 0: This key is not allowed to receive keys via the RTMK instruction. 

30 

# XLTKEY in 

- XLTKEY in = 1: This key is allowed to encrypt the input key to the TRANLATE KEY instruction. 

35 - XLTKEY in = 0: This key is not allowed to encrypt the input key to the TRANSLATE KEY instruction. 

# Key Form - This field is two bits long, indicating whether the KEK is a short (i.e., single length) key or a long (i.e., 
double length) key; and if the key is long, then the key half is the right half or the left half. 

40 # Link Control - Same description as that of KEK sender key 

# AV (Ant i- Variant) - Same description as that of Privacy keys. 

# Software bits - This field occupies 1 2 bits. 

45 

# CV version - Same description as that of Privacy keys. 

# Software-Enforced Usage - See also the CFAP section. 

so - CVKRKD (Control Vector KEK Receiver - Receive Data Key) 

- CVKRKP (Control Vector KEK Receiver - Receive PIN Key) 

- CVKRKK (Control Vector KEK Receiver - Receive KEK) 

55 

# Extension - Same description as that of Privacy keys. 

# Reserved Bits - Same description as that of Privacy keys. 



29 



EP 0 356 065 B1 

# Parity Bits - Same description as that of Privacy keys. 
Control Vector Format for ANSI KEK 

s Refer to Fig 21 . The following is a detailed description of each field and subfield of this figure. 

# CV Type - CV TYPE (maintype = "Key encrypting key (KEK)", subtype = "ANSI") 

# Export Control - Same description as that of Privacy keys. 

10 

# Usage 

# ARFMK - Specifies whether the key can be used as a key-encrypting key in the ARFMK instruction to ship keys 
to other nodes. 

15 

# ARTMK - Specifies whether the key can be used as a key-encrypting key in the ARTMK instruction to receive keys 
from other nodes. 

# AXLTKEY - Specifies whether the key can be used as a key-encrypting key in the AXLTKEY instruction to translate 
20 keys. Note that there is not indication of input translate key or output translate key on the ANSI KEK control vector. 

This is because ANSI KEKs are bi-directional. 

# APNOTR - Specifies whether transformations can be performed on this key to produce a partial notarising key 
that is allowed to later notarise other keys. Once the transformation is done, the resulting partial notarising key 

25 KKPN must have this APNOTR bit clear to zero so that KKPN will not be fed into the APNOTR instruction to compute 

another partial notarising key. 

# KEY Form - Same description as that of KEK sender keys. 

30 # Link Control - This field is not applicable to the ANSI KEK. See also the description of this field for KEK sender. 

# AV (Anti-Variant) - Same description as that of Privacy keys. 

# Software Bits. - This field occupies 12 bits. 

35 

# CV version - Same description as that of Privacy keys. 

# Software-Enforced Usage - None. 

40 # Extension - Same description as that of Privacy keys. 

# Reserved Bits - Same description as that of Privacy keys. 

# Parity Bits - Same description as that of Privacy keys. 

45 

Control Vector Format for Key Parts 

Refer to Fig. 22. The following is a detailed description of each field and subfield of this figure. 

so # CV TYPE - CV TYPE, where the last thre-e bits xxx of CV TYPE are set to zero but are checked by the instructions, 

(maintype = Key part, subtype = Not applicable) 

# Export Control - Same description as that of Privacy keys. 
ss # Key Form - Same description as that of KEK sender. 

# AV (Anti-Variant) - Same description as that of Privacy keys. 



30 



EP 0 356 065 B1 



# Software bits - This field occupies 1 2 bits. 

# CV version - Same description as that of Privacy keys. 
5 * Software- Enforced Usage - None. 

# Extension - Same description as that of Privacy keys. 

# Reserved Bits - Same description as that of Privacy keys. 

10 

# Parity Bits - Same description as that of Privacy keys. 
Control Vector Format for Intermediate ICV 

15 Refer to Fig. 23. The following is a detailed description of each field and subfield of this figure. 

# CV TYPE - CV TYPE, where the last three bits xxx of CV TYPE are set to zero but are not checked by the 
instructions (maintype = "Intermediate ICV", subtype = Not applicable) 

20 # Export Control - Same description as that of Privacy keys. The ICV keys are normally not imported ot other nodes 

except in the case of a hot backup. Thus, normally, this field assumes the value B'00' for an ICV control vector. 

# AV (Anti- Variant - Same description as that of Privacy keys. 
25 # Software Bits 

# CV VERSION - Same description as that of Privacy keys. 

# Software-Enforced Usage - None. 

30 

# Extension - Same description as that of Privacy keys. 

# Reserved Bits - Same description as that of Privacy keys. 
35 # Parity Bits - Same description as that of Privacy keys. 

Control Vector Format for Tokens 

Refer to Fig. 24. The following is a detailed description of each field and subfield of this figure. 

40 

# CV TYPE - CV TYPE, where the last three bits xxx of CV TYPE are set to zero but are not checked by the 
instructions (maintype = "Token", subtype = Not applicable). Tokens are secret quantities used to protect the integrity 
of Data keys stored in the Data Keys Dataset (DKDS). Data keys are stored in the DKDS in the form token+e*KM.C1 
(K),e*KM.C2(token). Token control vector. type is allowed in several instructions such as EMK, RTNMKand RTCMK. 

45 

# Export Control - Same description as that of Privacy keys. The ICV keys are normally not imported to other nodes 
except in the case of a hot backup. Thus, normally, this field assumes the value B'00' for an ICV control vector. 

# AN (Anti-Variant) - Same description as that of Privacy keys. 

so 

# Software Bits - 

# CV VERSION - Same description as that of Privacy keys. 
55 * Software- Enforced Usage - None. 

# Reserved Bits - Same description as that of Privacy keys. 
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# Extension - Same description as that of Privacy keys. 

# Parity Bits - Same description as that of Privacy keys. 
5 Instruction Set 

The instruction set described here is a common cryptographic function set which is implemented in the CF. There 
may be exceptions to this requirement; for instance, MDC can be implemented at a CFAP level. Other deviations in the 
instruction set implementation should be carefully considered based on security requirements and product environment. 

10 The instruction set is based on a control vector approach. There are several fields in the control vectors which may 

or may not be implemented in a particular system. However, the minimum control vector checking as described here 
must be performed in each system in the CF. If the full crypto separation is not required or only a subset of the instruction 
set is sufficient for a given application, the control vector checking can be excluded for the functions not implemented 
in a given design. (The checking on subtype fields in the control vector, an encoded field, ensures that control vectors 

'5 can not be mixed and matched in the crypto instructions using invalid combinations. This checking is crucial to security.) 

The instruction set equations represent the inputs required to the function and outputs expected from the function 
related to a cryptographic function described. Instead of passing actual data to the function, the implementation may 
pass the addresses of data to the function. This addressing would depend upon the given system implementation and 
is not described here. 

20 The equations describe all the parameters and data required to perform a given function. Depending upon the 

modes of the operation, some or all the parameters are used in the function, however, the fields in the equation have 
to be treated as inputs and outputs rather than the actual values of inputs and outputs as passed to the function in a 
given implementation. For example: the "A" field in the equation represent the data to be passed to a function, the 
physical form of this may be a 32 bit address pointing to the data to be fetched by the instruction from memory or to be 

25 stored to the memory. The data bus width from memory is also implementation dependent, whereas the input data to 
be encrypted or decrypted by crypto function operations is always a multiple of 8 bytes. 
There are two fundamental ways in which CV checking can be done. 

1. Test Bits in Control Vector : Test the control vector bits according to what they should be, if it does not match 
30 then set a condition code and abort the operation. For example, in ENCIPHER instruction a E B bit of the CV is tested 

for "1", if it is not one then the operation is aborted. For more complicated instructions, the testing is not as trivial 
as this, and we need to pass some parameters to specify the intent of input and output operation and the usage of 
control vector. For example, in generate key set (GKS), "mode" is specified to the instruction to generate a particular 
from of output, and the control vector checking has to be performed according to the "mode" specification. 
35 2. Set bits in Control Vector : Set a bit in control vector as appropriate then perform the operation. This does not 

require any testing of control vectors. For example, in ENCIPHER instruction "E" bit is set in the control and the 
operation is performed. Now, each instruction has to know, what bits to set and under what conditions? This strategy 
may not work in all cases. For instance, how would the instruction know what is the bit setting for "target control"? 
This means, there has to be a parameter specified to the instruction indicating to choose a particular setting in the 
40 control vector. This approach will take away all the flexibility in the control vector specification. 

Either of the above two techniques will satisfy the cryptographic requirements of the control vector checking. We 
have chosen the "Test bits in Control vector" approach (no bits in the control vector are set by the instruction) for the 
following reasons: 

45 

1 . Instruction does not have to know what bits to set nor when. 

2. It is very flexible to pass a parameter like "mode" and get the possible combination of outputs, and provide a 
combination of inputs to the instruction. 

3. If the setting is hardcoded in the CF, then it is very hard to make extension to the architecture, and it is also very 
so difficult to know all the possible combinations ahead of time. 

4. It simplifies hardware implementation, and provides greater flexibility to software. 

5. It preserves the intent of control vectors: Control vectors (at the present time) are used for cryptographic separation 
and specifically for security reasons. Control vectors are not used in CA for "specifying an operation or a function 
to the instruction". In other words, control vectors are not like an "extended opcode" for the instruction. 

55 

Encode (ENC) 
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- Equation KD, A -- eKD(A) 
Inputs: 

KD 64 bit clear key 
5 A 64 bit plain text 

Outputs: eKD(A) 64 bit encrypted data 

Description: The encode function is used to encipher an 8 byte plain text data in ECB mode using a 64 bit clear key. 
10 No control vector is passed to this instruction. 

Fig. 25 is a block diagram of this instruction. 

#CC: 

15 

1 . successful operation 

2. unsuccessful operation (error) 

20 NOTE: Unsuccessful operation can be any hardware error specific to a given implementation. The condition codes 

(CC described here merely represent suggested condition codes for the instruction, however, there may be more con- 
dition codes implemented in a given system. Furthermore, the CC codes do not represent the actual condition codes 
that have to be passed by the function in a given implementation, the numbering used here is for a convenient description 
of crypto architecture. 

25 

# Control Vector Checking: - None. 
Decode (DEC) 

30 

Equation: KD, eKD(A) -- A 
Inputs: 

35 KD 64 bit clear key 

eKD(A) 64 bit encrypted data 

Outputs: A 64 bit encrypted data 

40 Description: The decode function is used to encipher an 8 byte plain text data in ECB mode using a 64 bit clear key. 

No control vector is passed to this instruction. 
Fig. 26 is a block diagram of this instruction. 

#CC: 

45 

1 . successful operation 

2. unsuccessful operation (error) 

# Control Vector Checking: - None 

50 

Encipher (ENCO 



S5 - Equation: e*KM.C1 (KD1 ), ICV, A, n, C1 — eKD1 (ICV.A) 
Inputs: 

e*KM.C1 (KD1 ) 64 bit data key (KD1) triple encrypted under the master key (KM) with a control vector C1 . 
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ICV 64 bit encrypted data 

NOTE: Encrypted ICVs are managed by CFAP as described in the "ICV/OCV Management" and "Software Inter- 
face." If output chaining value (OCV) is required, the last 8 byte output (En) must be used as OCV, however, this is not 
5 a standard approach. Each system implementation treats the encryption and decryption of the last block differently 
Refer to "Software Interface" for more details on the last block treatment and OCV generation techniques. CFAP handles 
all the possible last block encipherment and decipherment and also OCV management. 

A Data to be encrypted, in multiples of 8 byte blocks. 

w 

The 8 byte blocks are A1, A2,...An. If the last block An is not a multiples of 8 bytes, padding should be performed 
by CFAP before calling this instruction. CF instructions always assume multiples of 8 bytes data as inputs and outputs. 

n number of 8 byte blocks to be encrypted. 

15 

n should be as large as possible, however, this may be system dependent. CA does not define any maximum limit on 
n. For example: If number of 8 byte blocks = 10,000 and n max = 4,000, then Encipher instruction will be invoked as 
follows: 

20 — Encipher n = 4000 
Encipher n = 4000 

- Encipher n = 2000 

NOTE: After each call of Encipher, the last 8 bytes enciphered data En (OCV) has to be fed back as ICV input to 
25 the next Encipher call. 

c1 64 bit control vector for data key (KD1 ). 

- Outputs: ekD1 (ICV, A) encrypted data, n blocks, each block is 8 bytes (E1 , E2..En). 

30 Description: The input data is encrypted via the CBC mode of DEA encryption. Multiples of 8 byte blocks are en- 

crypted by this instruction until all n blocks are encrypted. 

The architecture defines only plain ICV input to the function. If encrypted ICV is required, the ICV can be encrypted 
using a data key (KD2) using encipher instruction. Encrypted ICVs can be decrypted using decipher instruction. All the 
encrypted ICVs and OCV's are managed by the CFAP program. 
35 |f the input data is not in multiples of 8 byte blocks then padding must be done. This padding has to be performed 

by CFAP before invoking the encipher function. 
Fig. 27 is a block diagram of this instruction. 

#CC: 

40 

1 . successful operation 
- 2. C1 is invalid 

3. unsuccessful operation (error) 

45 # Control Vector Checking: 

1 . Checking on C1 

-- CV type = "data/compatibility" or "data/privacy" or "data/ANSI' 
50 — E usage bit = 1 

- reserved (48:63) = X'0' 

NOTE: For all the instructions described here, control vector checking implies that if the check is not passed then 
the instruction must be aborted and the corresponding control vector invalid condition code (CC) be turned on. If there 
55 are one or more checks to be performed on the control vectors, all the checks are performed and all the checks have 
to be passed to perform the operation. If any of the checks fail, the operation must be aborted. 
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Decipher (DECI) 



5 - Equation: e*KM.C1(KD1), ICV, eKD1(ICV,A), n, C1 -- A 
Inputs: 

e*KM.C1(Kd1) 64 bit data key (KD1) triple encrypted under the master key (KM) with a control vector C1. 
ICV 64 bit plain input chaining value. 

10 

NOTE: Encrypted ICVs are managed by CFAP as described in the "ICV/OCV Management: and "Software Inter- 
face." If output chaining value (OCV) is required, the last 8 byte input (En) must be used as OCV, however, this is not 
a standard approach. Each system implementation treats the encryption and decryption of the last block differently. 
Refer to "Software Interface" for more details on the last block treatment and OCV generation techniques. CFAP handles 
is all the possible last block encipherment and decipherment and also OCV management. 

eKdl (ICV, A) encrypted data, n blocks, each block is 8 bytes (E1 , E2..En). 
n number of 8 byte blocks to be decrypted. 

20 n should be as large as possible, however, this may be system dependent. CA does not define any maximum limit 

on n. 

NOTE: After each call of Decipher, the last 8 bytes enciphered data En (OCV) has to fed as input ICV to the next 
Decipher call. This is being managed by CFAP. For example: if number of 8 byte blocks = 10,000 and n max = 4000, 
then Decipher instruction will be invoked as follows: 

25 

- Decipher n = 4000 
Decipher n = 4000 
Decipher n = 2000 

30 C1 64 bit control vector for data key (KD1). 

- Outputs: A Plain data, in a multiples of 8 byte blocks. The 8 byte blocks are A1 , A2,...An. 

Description: The input data is decrypted via the CBC mode of DEA encryption. The multiples of 8 byte blocks are 
decrypted by this instruction until all n blocks are decrypted. 
35 The architecture defines only plain ICV input to the function. If encrypted ICV is required, the CV can be encrypted 

using a data key (KD2) using encipher instruction. Encrypted ICVs can be decrypted using decipher instruction. All the 
encrypted ICVs and OCV. = 's are managed by the CFAP. 
Fig. 28 is a block diagram of this instruction. 

40 #CC: 

1 . successful operation 

2. C1 is invalid 

3. unsuccessful operation (error) 

45 

# Control Vector Checking 
1 . Checking on C1 

so CV type = "data/compatibility" or "data/privacy" or "data/ANSI" 

- D usage bit = 1 

- reserved (48:63) = X'0' 

GENMAC (GMAC) 



# Equation: e*KM.C1(KD2 = 1),[e*KM.C2(KD2)],ICV[e*KM.C3(OCV)] l A, n, ICVtype.output-type, mac-enc. 
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C1,[C2],[C3] — MAC (64 brt) 
or 

e*KM.C3(OCV) 
- Inputs: 

5 

e*KM.C1 (KD1 ) KD1 is a MAC generation key for single encrypting MAC, triple encrypted under KM with a control 
vector C1. 

e*KM.C2(KD2) KD2 is an optional MAC generation key for triple encrypting MAC, triple encrypted under KM with 
a control vector C2. This is an optional input required for triple encrypting mac output if mac-enc= 1 . 
io ICV ICV equal to zero is the default Initial Chaining Value, and is standard to CA architecture, ANSI 

X9.9 and ANSI X9.19. Non-zero plain ICV can also be used to be compatible with systems which 
require plain ICV input. Encrypted ICV input is not supported by CA as it was found that it does 
not provide any more security for the function. Encrypted intermediate ICVs are supported by CA. 

is NOTE: Encrypted ICVs if required are managed by CFAP as described in the ICV/OCV Management" and "Software 

Interface." 

e*KM.C3(OCV) This is a 64 bit intermediate ICV encrypted under the master key with a special control vector C3. This 



is an optional input which must be provided if large blocks of data (/n) are used to generate MAC. 
20 Decrypting the ICV is done internal to the function. Intermediate OCV can not be shipped from the 

local node, as it is stored under the master key with a control vector in the form for local use only. 
A Data to be MAC'd, in multiples of 8 byte blocks (A1 , A2... An), 

n number of 8 byte blocks to be MAC'd. 



25 n should be as large as possible, however, this may be system dependent. CCA does not define any maximum limit 

on n. If large number of blocks have to be MAC'd then GMAC is invoked multiple number of times until all blocks are 
complete. For example: if n max is 4000 for the system, and the data to be MAC'S are 1 0,000 8 byte blocks, then GMAC 
is invoked as follows: 

30 - GMAC n = 4000,outpuMype = 1 .ICV-type = 0 

- GMAC n - 4000,output-type = 1 .ICV-type = 2 
~ GMAC n = 2000,output-type = 1 JCV-type = 2 

NOTE: After each call of GMAC, the intermediate ICV e*KM.C3(OCV) must be fed back to next GMAC call as ICV 
35 input. The decryption of this intermediate ICV must be done internally in the CF 

ICV-type ICV-type indicates whether the ICV passed to the function is zero, plain, or intermediate. 

Intermediate ICV is triple encrypted under the master key with a control vector C3. Zero ICV is a default value. 

40 

- 0: zero ICV (default) 
-- 1: plain ICV 

-- 2: intermediate ICV (OCV) 

45 output-type indicates the stage of the mac generation process to the instruction. 

~ 0: MAC output 

- 1 : Intermediate ICV output (OCV) 

50 mac-enc mac-enc indicates a single or triple encryption mac output 

- 0: single encrypting mac output 

- 1: triple encrypting mac output(ANSI 9.19 requirement) 

55 C1.C2.C3 64 bit control vectors for KD1 , KD2, and OCV respectively. C2 and C3 are optional inputs to the in- 

struction, C2 must be input if mac-enc = 1, and C3 must be input if iCV-type = 2 or output-type = 1. 

Outputs: 
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MAC is a 64 bit output, resulted from the single encryption or triple encryption of the final input block of 

data, depending upon mac-enc parameter. This output is valid only if output-type = 0. 
e*KM.C3(OCV) OCV is a 64 bit intermediate ICV triple encrypted under KM with control vector C3. 

This output is valid only if output-type = 1 . MAC output and Intermediate OCV outputs both must not be output at 
the same time for security reasons. 

Description: The input data is encrypted with CBC mode of DEA encryption, and the final block of encrypted data 
is output. There are two modes, the single encryption mode and triple encryption mode. With the single encryption mode, 
a single key KD1 is used to create the MAC. In the triple encryption mode, the single encryption mode is employed with 
KD1 to create a MAC, except the MAC is then decrypted with KD2, and re-encrypted again with KD1 to produce the 
final 64 bit MAC. 

The instruction outputs 64 bit MAC, however, X9.9 specifies 32 bit MAC which is 32 left most bits of the 64 bit MAC 
output. CFAP has to extract the appropriate MAC bits from the 64 bit MAC output. 

ICV is zero as a standard and optionally can be a plain or intermediate ICV to GMAC instruction. If encrypted ICVs 
are required then CFAP must encrypt ICV under (KDS) and must pass a plain ICV to the GMAC instruction. The ANSI 
X9.9 MAC standard specifies a zero ICV for the first block and thus is defined here as a standard input. However, 
architecture provides plain and intermediate inputs to satisfy every possible need of MAC generation. 

If MAC generation is required for the blocks greater than n, intermediate ICV option must be used to generate MAC. 
This requirement provides additional security by not exposing intermediate ICVs in clear. 

If the data block is not multiples of 8 byte blocks, padding must be done. The padding has to be performed by the 
CFAP before invoking this function. MAC computation must be for the binary data as specified by the ANSI X9.9-1986 
section 5.0 and Coded character sets authentication if needed must be implemented by CFAP. 

Fig. 29 is a block diagram of this instruction. 

#CC: 

1 . successful operation 
- 2. C1 is invalid 

3. C2 or C3 is invalid 

4. unsuccessful operation (error). 

# Control Vector Checking: 

1. Checking on C1 

CV type = "data/compatibility 0 or "data/mac" or "data/ANSI 0 
-- MG usage bit = 1 

- reserved (48:63) = X'O' 

2. Checking on C2 if (mac-enc = 1 ). 

- C V type = "data/compatibility" or "data/mac" or "data/ANSI n 

- MG usage bit = 1 

-- reserved 48:63) = X'O' 

3. Checking on C3 if (ICV-type = 2 OR output-type = 1 ). 

- CV type = "Intermediate ICV 
Verify MAC (VMAC) 



Equation: e*KM.C1 (KD1), [e*KM.C2(KD2)]ICV[e*KM.C3(OCV)l,A,MAC, n, ICV-type,out- 

put-type,mac-enc,mac-len, C1, [C2],[C3] 

yes/no 

or 

e*KM.C3(OCV) 
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Inputs: 

e*KM.C1 (KD1 ) KD1 is a mac verification key for single encrypting mac, triple encrypted under KM with a control 
vector C1. 

e*KM.C2(KD2) KD2 is a mac verification key for triple encrypting mac, triple encrypted under KM with a control 
vector C2. 

This is an optional input required for triple encrypting mac output if mac-enc = 1 . 

ICV ICV equal to zero is the default Initial Chaining Value, and is standard to CA architecture .ANSI X9.9 and ANSI 
X9.19. 

Non-zero plain ICV can also be used to be compatible with systems which require plain ICV input. Encrypted ICV 
input is not supported by CA as it was found that it does not provide any more security for the function. Encrypted 
intermediate ICVs are supported by CA. 

NOTE: Encrypted ICVs if required are managed by CFAP as described in the "ICV/OCV Management" and "Software 
Interface." 

e*KM.C3(OCV) This is a 64 bit intermediate ICV encrypted under the master key with a special control vector C3. 

This is an optional input must be provided if large blocks of data (] n) are used to verify MAC. Decrypting the ICV 
is done internal to the function. Intermediate OCV can not be shipped from the local node, as it is stored under the 
master key with a control vector in the form for local use only. The intermediate ICVs must be secret in the MAC veri- 
fication process to protect from attacks. 

A Data used in MAC, in multiples of 8 byte blocks (A1 ,A2...An). 
MAC 64 bit MAC input to the instruction either single or triple encrypted. 

By default, only left most 32 bits of this MAC are used for MAC comparison, mac-len may be used to explicitly 
specify other comparison lengths. 

n number of 8 byte blocks MAC'ed. 

n should be as large as possible, however, this may be system dependent. If large number of blocks have to be 
mac verified then VMAC is invoked multiple number of times until all blocks are complete. For example: if n max is 4000 
for the system, and the data to be verified are 10,000 8 byte blocks, then VMAC is invoked as follows: 

~ VMAC n = 4000,output-type = 1 ,ICV-type = 0 

- VMAC n = 4000,output-type = 1 ,ICV-type = 2 

- VMAC n = 2000,output-type = 0,ICV-type = 2 

NOTE: After each call of VMAC, the intermediate ICV e*KM.C3(OCV) must be fed back to next VMAC call as ICV 
input. The decryption of this intermediate ICV must be done internally in the CF. 

ICV-type ICV-type indicates whether the ICV passed to the function is zero, plain, or intermediate. 

Intermediate ICV is triple encrypted under the master key with a control vector C3. 

- 0:zero ICV (default) 

- 1:plainlCV 

- 2: intermediate ICV (OCV) 

output-type indicates the stage of the mac verification process to the instruction 

- 0 : MAC Verification output 

- 1 : Intermediate ICV output (OCV) 

mac-enc mac-enc indicates a single or triple encryption mac input. 
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— 0 : single encrypting mac input 

— 1 : triple encrypting mac input (ANSI 9.19 requirement) 

mac-len mac-len specifies the number of bytes of the mac to be compared. 

5 

4 left most bytes are compared as a default. 

— 0:4 left most bytes 

— 1:5 left most bytes 
10 - 2:6 left most bytes 

— 3:7 left most bytes 
~ 4:8 bytes 

NOTE: provision of 4, 5, 6, 7, 8 byte MAC verification may subvert MAC generation process for 8 byte MAC. The 
1$ solution to this problem forms no part of the present invention and is not further discussed herein. 

C1 ,C2,C3 64 bit control vectors for KD1 , KD2, and OCV respectively. 

C2 and C3 are optional inputs to the instruction, C2 is required if mac-enc = 1, and C3 is required if ICV-type = 2 
20 or output-type = 1 . 

Outputs: 

yes/no mac is verified or not. 

25 e*KM.C3(OCV) OCV is a 64 bit intermediate ICV triple encrypted under KM with control vector C3. This is an 

optional output valid for output-type = 1 . 

Description: The input data is encrypted with CBC mode of DEA encryption using data key KD1 and 32 left most 
bits of the final encrypted block are compared for equality with the supplied MAC. 32 bit MAC compare is a default value, 
30 and other comparisons must be made as specified by the mac-len parameter. CC = 1 is set for macs equal and CC = 
2 is set if macs are not equal. There are two encryption modes: single encryption mode, a single key KD1 is used to 
create the MAC. In the triple encryption mode, the single encryption mode is employed with KD1 to create a MAC, except 
the MAC is then decrypted with KD2, and re-encrypted again with KD1 to produce the final 64 bit MAC. The MAC is 
generated as specified by mac-enc input and then compared with the supplied mac to the function. 
35 The first ICV is zero as a standard and optionally can be plain. Intermediate ICV must be used if the mac'd data is 

greater than n blocks in length. 

If the data block is not multiples of 8 byte blocks, padding must be done. The padding has to be performed by the 
CFAP before invoking this instruction. 

Fig. 30 is a block diagram of this instruction. 

40 

#CC: 

1 . MACs equal 

2. MACs not equal 
45 3. C1 is invalid 

4. C2 or C3 is invalid 

5. unsuccessful operation (error). 

# Control Vector Checking: 

so 

1. Checking on C1 

- CV type = "data/compatibility 0 or "data/mac 0 or "data/ANSI" 

- MV usage bit - 1 

55 - reserved (48:63) = X'O' 

2. Checking on C2 if (mac-enc = 1 ). 
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- CV type = "data/compatibility" or "data/mac" or "data/ANSI " 

- MG usage bit = 1 

- reserved 48:63) = X'O' 

3. Checking on C3 if (ICV-type = 2 OR output-type = 1 ). 
CVtype = "Intermediate ICV" 
Translate Cipher Text (TCTXT) 



- Equation: e*KM.C1 (KD1 ),ICV1 ,eKD1 (ICV1 ,A),e*KM.C2(KD2),ICV2, n, C1 , C2 
eKD2(ICV2,A) 
Inputs: 



e*KM.C1 (KD1 ) KD1 is an input data key, triple encrypted under KM with a control vector C1 . 

ICV1 64 bit clear ICV. 

eKD1 (ICV1 ,A) KD2 is an output data key, triple encrypted under KM with a control vector C2 

ICV2 64 bit clear ICV 

n Number of 8 byte blocks of data to be translated. 

C1 , C2 Control vectors for KD1 , KD2 respectively. 



Outputs: eKD2(ICV2,A) outputs Data A encrypted with data key KD2 using ICV2. 

Description: Translate cipher text instruction translates data from one data key and ICV to another data key and 
ICV. This instruction operates with data/xlt keys, and data/compatibility keys. CV keys or CV = 0 keys can be used to 
translate data, no mix and match of these key types are permitted by this instruction. The data can be up to n 8 byte 
blocks, the translation is done in the crypto facility without exposing the clear data outside the crypt facility. 

The ICV inputs ICV1 and ICV2 can only be plain ICV inputs to the instruction. No intermediate ICV is provided by 
the instruction. If more than n blocks of data have to be translated, and the data has to be chained then CFAP has to 
pass the last 8 byte encrypted block(En) as input to ICV. If encrypted ICVs are used then CFAP must decipher the ICVs 
before passing ICVs to the instruction. 

NOTE: The xlate Ciphertext instruction is specifically designed to operate with CV-only keys (i.e., xlate data keys). 
There is no compatibility mode xlate ciphertext option offered. To get around this, the xlate ciphertext instruction will 
accept data keys with the D and E attributes as well as the XDin and XDout attributes. But this is provided as a service 
to reduce the accidental exposure of clear data, since an insider adversary could recover data unclear using the decipher 
instruction. It is not possible to isolate the xlate ciphertext keys in the compatibility mode, and to architect a control vector 
for this would give an illusion of security, when in fact, an attack could be perpetrated with the RTMK instruction by 
importing an intended xlate key (sent over CV = 0 channel) as a decipher key. Thus, the xlate ciphertext data channel 
could be subverted by deciphering data sent over that channel. 

Fig. 31 is a block diagram of this instruction. 



#CC: 



1 . successful operation 

2. C1 or C2 is invalid 

3. unsuccessful operation (error) 



# Control Vector Checking: 
1. Checking on C1 



- CV type = "data/xlt" or "data/compatibility" 

- If (C V type = "data/xlt") then XDin = 1 
-- reserved (48:63) = X'O* 



2. Checking on C2 if (mac-enc = 1 ). 



40 



EP 0 356 065 B1 



-- CV type = "data/bet" or "data/compatibility" 

- If (CV type = "data/xlt") then XDout = 1 . 

- reserved 48:63) = X'O' 

s - 3. Checking on C1 and C2 

- CV type(C1 ) = 'CV type (C2) 
Generate Key Set (GKS) 

10 



- Equation: OP-OP mode mode, C3, C4 — e*KM.C3(K), e*KM.C4(K) 

- Equation: OP-EX mode mode, C2L, C2R, C3, C4, e*KM.C2L(KEK2L), e*KM.C2R(KEK2R) 
is — e*KM.C3(K),e*KEK2.C4(K) 

- Equation: EX-EX mode mode, C1L, C1R, C2L, C2R, C3, C4, e*KM.C1 L(KEK1 L),e*KM.C1 R(KEK1 R), 
e*KM.C2L(KEK2L),e*KM.C2R(KEK2R) 

— e*KEK1.C3(K), e*KEK2.C4(K) 

- Equation: OP-IM mode mode, C2L, C2R, C3, C4, e*KM.C2L(KEK2L), e*KM.C2R(KEK2R) 
20 — e*KM.C3(K), e*KEK2.C4(K) 

- Equation: IM-EX mode mode, C1L, C1R, C2L, C2R, C3, C4, e*KM.C1 L(KEK1 L), e*KM.C1 R(KEK1 R), e*KM.C2L 
(KEK2L), e*KM.C2R(KEK2R) 

— e*KM.C3(K), e*KEK2.C4(K) 
Inputs: 

25 

mode indicates the input and output formats of GKS instruction, and the key generation modes. 

The explanation for the key generation modes are further described in the "KEY MANAGEMENT" section. 

30 - 0 : OP-OP (operational - operational) 

- 1 : OP-EX (operational - export) 

- 2 : EX-EX (export - export 

- 3 : OP-IM (Operational - import) 
~ 4 : IM-EX (import - export 



35 



C1 L.C1 R These are 64 bit control vectors, left and right control vectors for 1 28 bit KEK1 . 



C1 L is the control vector for KEK1 L and C1 R is the control vector for KEK1 R key. The actual implementation may 
pass only one CV and let the CF set the "key form" bits in the control vector implicitly. The CA architecture has chosen 
40 to pass the left and right control vectors separately for KEKs. CFAP has to generate and manage these two types of 
CVs for the KEKs. 

C2K.C2R These are 64 bit control vectors, left and right control vectors for 1 28 bit KEK2. 
45 C2L is the control vector for KEK2L and C2R is the control vector for KEK2R key. 

C3.C4 These are 64 bit control vectors for output key. 

e*KM.C1L(KEK1 L) KEK1 L is a 64 bit left key encrypting key, which is a part of 1 28 bit key encrypting key KEK1 , triple 
so encrypted under the master key KM with a control vector C1 L. 

e*KM.C1R(KEK1R) KEK1R is a 64 bit right key encrypting key, which is a part of 128 bit key encrypting key KEK1, 
triple encrypted under the master key KM with a control vector C1R. 

55 e*KM.C2L(KEK2L) KEK2L is a 64 bit left key encrypting key, which is a part of 1 28 bit key encrypting key KEK2, triple 
encrypted under the master key KM with a control vector C2L. 

e*KM.C2R(KEK2R) KEK2R is a 64 bit right key encrypting key, which is a part of 128 bit key encrypting key KEK2, 
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triple encrypted under the master key "M with a control vector C2R. 

NOTE: For compatibility purposes the architecture supports both single length (64 bits) and double length (1 28 bits) 
key encrypting keys (KEKs). All KEKs, however, are stored on the CKDS (Key Storage) as 128 bit keys. A true double 

5 length key KEK = KEKleft 11 KEKright (where KEKIeft is left-most 64 bits and KEKright are rightmost 64 bits of KEK) is 
stored triple encrypted under the master key *KM using some CV LC and CR. The stored form is 1 28 bits denoted by : 
e*KM.C(KEK) = e*KM.CL(KEKIeft) 1 1 e*KM.CR(KEKright). A single length key KEK is handled by replicating key to form 
a 1 28 bit key; KEK 11 KEK is then triple encrypted under *KM and a control vector CL.CR. The stored form is therefore 
128 bits denoted by : e*KM.C(KEK\\KEK) = e*KM.CL(KEK) 11 e*KM.CR(KEK). The "key form" bits for replicated KEK 

10 control vector are "01 " in each of control vectors CL, and CR so that the key can be recovered at the destination which 
only stores KEK in 64 bit form. The "key form" bits for normal KEK control vector are "10" for CL and "1 1 " for CR so that 
they achieve complete separation and preserve 2**112 work factor. 

Outputs: 

15 

e*KM.C3(K) K is a 64 bit randomly generated key, triple encrypted under KM with a control vector C3. 

Control vector C3 is always used. The Key K is odd parity adjusted. This key is an operational key that can be used 
internal to the node. 

20 

e*KM.C4(K) K is a 64 bit randomly generated key, triple encrypted under KM with a control vector C4. 

Control vector C4 is always used. The Key K is odd parity adjusted. This key is always used. This key is a operational 
key that can be used internal to the node. 

25 

e*KEK1 .C3(K) K is a 64 bit randomly generated key, encrypted under KEK1 with a control vector C3. 

Control vector C3 is always used. The Key K is odd parity adjusted. 1 28 bit KEKs can be generated by calling GKS 
twice with C3L and C3R in place of C3 control vector. CFAP must control the passage of these control vectors as needed. 

30 

e*KEK2.C4(K) K is a 64 bit randomly generated key, encrypted under KEK2 with a control vector C4. 

Control vector C4 is always used. The Key K is odd parity adjusted 1 28 bit KEKs can be generated by calling GKS 
twice with C4L and C4R in place of C4 control vector. CFAP must control the passage of these control vectors as needed. 

35 Description: The GKS instruction generates a random, odd parity adjusted 64 bit key, with two attributes indicated 

by the two control vectors C3 and C4. A 128 bit parity adjusted key can be generated by issuing the GKS instruction 
twice. The GKS instruction can only ship keys to control vector systems on a CV channel. No compatibility mode keys 
are generated by the GKS instruction. All compatibility mode keys are generated using KGEN and must be shipped via 
RFMK. A compatibility mode key may be shipped on a CV channel (using CV on the link) or a CV = 0 channel. 

40 The GKS instruction provides high security by creating only two copies of the generated key, which are encrypted 

under keys belonging to two target systems. The control vectors associated with these two copies of the generated key, 
designated C3 and C4, may be the same or different depending on the intended usage of the keys. 
The GKS instruction is used to generate and distribute the keys shown in Fig. 32. 

All keys in the CA system are output triple encrypted (EDE) under a 128 bit KEK. A replicated 64 bit KEK is used 
45 to send keys to nodes that only support 64 bit KEKs. If a receiving node supports 128 bit KEKs it can recover a key by 
triple decryption (DED). If the recipient only supports 64 bit KEKs, a key can be recovered by single decryption. All KEKs 
are stored under the master key as e*KM.C1L(KEKL) 11 e*KM.C1 R(IKEKR) which is a 128 bit encrypted quantity. C1L 
is a left part key control vector and C1 R is a right partkey control vector. The C1L and C1 R control vectors have a "key 
form" field which distinguishes from a left and right part. This eliminates an insider attack on double length keys (where 
so left and right parts are unequal) of work factor about 2**56. Insider attacks on a 1 28 bit key should be in the order of 2**56). 
Fig. 33 is a block diagram for this instruction. 

#CC: 

55 - 1. successful operation 

2. ClLorClRis invalid 

3. C2L or C2R is invalid 

4. C3 is invalid 
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5. C4 is invalid 

6. unsuccessful operation (error). 

# Control Vector Checking: If mode = O(OP-OP), then do the following checking: 

1 . Checking on C3 

- CV type = "data/priv" or 'data/mac' 

- anti-variant(30) = '0' 
-- anti-variant(38) = T 
~ reserved(48:63) = X'O' 

2. Checking on C4 

- CV type = "data/priv" or "data/mac" 
-- anti-variant(30) = '0* 

- anti-variant(38) = '0' 
reserved(48:63) = X'O' 

3. Checking on C3 & C4 

- Fig. 34 shows the valid combinations of C3 and C4 attributes which must be checked. Any combination 
other than those in the table is cryptographically invalid and thus must not be allowed. 

If mode = 1 (OP-EX), then do the following checking: 

1 . Checking on C2L 

-- CV type = n KEK/sender M 

GKS usage bits (1) = 1 
-- reserved(48:63) = X'O' 

2. Checking on C2R 

- CV type = "KEK/sender" 

- GKS usage bits (1) = 1 

- reserved(48:63) = X'O' 

3. checking on C3 

- CV type = "data/priv" or "data/mac" or "data/xlt" or "KEK/sender" or "KEK/receiver" or "PIN/PEK" 

- anti-variant(30) = '0' 

- anti-variant(38) = T 

- reserved(48:63) = X'O* 

4. Checking on C4 

CV type = "data/priv" or "data/mac" or D data/xlt" or "KEK/sender" or "KEK/receiver" or PIN/PEK" 
anti-variant(30) = '0' 

- anti-variant(38) = T 

- reserved(48:63) = X'O* 

5. Checking on C3 & C2L.C2R 

~ If CV type (C3) = "KEK/sender" or "KEK/receiver" & key form(C3) = '10' or '1 V then key form (C2L) = '10' & key 
form (C2R) = '1V 

6. checking on C4 & C2L.C2R 
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- If CV type (C4) = "KEK/sender" or "KEK/receiver" & key form(C4) = '10' or '11' then key form (C2L) = '10* & key 
form (C2R) = '11' 

7. Checking on C2L & C2R 

- Fig. 35 shows the valid combinations of C2L and C2R attributes which must be checked. Any combination other 
than those in the table is cryptographicatly invalid and thus must not be allowed. 

8. Checking on C3 & C4 

- C3 and C4 must satisfy the combinations shown in Fig. 36. No other combinations are permitted. 
If mode = 2(EX-EX), then do the following checking. 

1 . Checking on KEK1 and KEK2 

-- KEK1 L 11 KEK1 R = KEK2L 1 1 (1 28 bit keys) 

NOTE: Checking the KEKs are not equal will ensure that BiDi keys are not shipped to a node. 

2. Checking on C1L 

CV type = "KEK/sender" 

- GKS usage bits(2) = 1 
reserved (48:63) = X'O 1 

3. Checking on C1R 

- CV type = "KEK/sender" 

- GKS usage bits(2) = 1 
-- reserved (48:63) = X'O' 

4. Checking on C2L 

- CV type = "KEK/sender" 

- GKS usage bits(2) = 1 

- reserved (48:63) = X'O' 

5. Checking on C2R 

-- CV type = "KEK/sender" 
-- GKS usage bits(1) = 1 
-- reserved (48:63) = X'O' 

6. Checking on C3 

- CV type = "data/priv" or "data/mac 0 or data/xlt" or "KEK/sender" or "KEK/receiver" or "PIN/PEK" 

- anti-variant(30) = '0' 
« anti-variant(38) = T 

-- reserved(48:63) = X'O' 

7. Checking on C4 

- CV type = "data/priv" or "data/mac" or data/xlt" or "KEK/sender" or "KEK/receiver" or "PIN/PEK" 

- anti-variant(30) = '0' 

- anti-variant(38) = T 

- reserved(48:63) = X'O' 
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8 Checking on C1 L & C1 R 

- same as described in Fig. 35 
9. Checking on C2L & C2R 

- same as described in Fig. 35 
10 Checking on C3 & C4 

~ same as described in Fig. 36. 

11. Checking on C3 & C2L, C2R 

- If CV type (C3) = "KEK/sender" or "KEK/receiver" & key form(C3) = '10' or '1 1 ' then key form (C2L) = '10' & key 
form (C2R) = , 1V 

12. Checking on C4 & C2L.C2R 

- If CV type (C4) = "KEK/sender" or "KEK/receiver" & key form(C4) = '10' or '1 1 ' then key form (C2L) = '10' & key 
form (C2R) = , 1V 

If mode = 3(OP-IM), then do the following checking: (This mode supports file applications) 
- 1. Checking on C2L 

~ CV type = "KEK/receiver" 

- GKS usage bits(1)= 1 

- reserved(48:63) = X'0' 

- 2. Checking on C2R 

- CV type = "KEK/receiver" 
« GKS usage bits(1)= 1 

- reserved(48:63) = X'0' 

3. Checking on C3 

CV type = "data/priv" or "data/mac" or data/xlt" 
« anti-variant(30) - '0' 
-- anti-variant (38) = '1' 

reserved(48:63) = X'0' 

5. Checking on C2L & C2R 

- same as described in Figure 35. 

6. Checking on C3 & C4 

~ Figure 37 shows the valid combinations of C3 and C4 attributes which must be checked. Any combination other 
than those in the table is cryptograph ically invalid and thus must not be allowed. 

If mode = 4(IM-EX), then do the following checking: (This mode is used for IBM SNA multi-domain application) 

1. Checking on C1L 

CV type = "KEK/receiver" 

- GKS usage bits(0) = 1 
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- reserved(48:63) = X'O' 

2. Checking on C1R 

CV type = "KEK/receiver" 
GKS usage bits(O) = 1 
reserved(48:63) = X'O' 

3. Checking on C2L 

-- CV type = "KEK/sender" 

- GKS usage bits(O) = 1 
reserved(48:63) = X'O* 

4. Checking on C2R 

-- CV type = "KEK/sender" 

- GKS usage bits(O) = 1 

- reserved(48:63) = X'O' 

5. Checking on C3 

-- CV type _ "data/priv" or -data/mac" or data/xlt" or "KEK/sender" 

- anti-variant(30) = '0' 

- anti-variant(38) = 'V 

- reserved(48:63) = X'O' 

6. Checking on C4 

-- CV type = "data/priv" or "data/mac" or data/xlt" "KEK/sender" or "KEK/receiver" or "PIN/PEK" 
-- anti-variant(30) = '0' 

- anti-variant(38) = T 

- reserved(48:63) = X'O' 

7. Checking on C1L & C1R 

- same as described in Figure 35. 

8. Checking on C2L & C2R 

same as described in Figure 35. 

9. Checking on C3 & C4 

- same as described in Figure 36. 

10. Checking on C3 & C2L.C2R 

- If CV type (C3) = "KEK/sender" or "KEK/receiver" & key form(C3) - '10' or '11' then key form(C2L) - '10' & key 
form (C2R) = '11\ 

11. Checking on C4 & C2L.C2R 

- If CV type (C4) = "KEK/sender" or "KEK/receiver" & key form(C4) = '10' or '11' then key form(C2L) = '10' & key 
form (C2R) = '11\ 
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Re-encipher From Master Key (RFMK) 



5 - Equation: dist-mode,e*KM.C1 L(KEK1 L),e*KM.C1 R(KEK1R),e*KM.C2(K), C1 L.C1 R.C2.C3 — e*KEK1 .C3(K) 
Inputs: dist-mode indicates the channel type used to ship a key. 

For example, CV, CV = 0 channels are used to ship keys. 

10 0: CV = 0 (channel) 

— 1 : CV (channel 

e*KM.C 1 L(KEK1 L) KEK1L is a 64 bit left key encrypting key, which is a part of 128 bit key encrypting key KEK1, triple 

encrypted under the master key KM with a control vector C1 R. 
15 e*KM.ClL(KEKlL) KEK1L is a 64 bit right key encrypting key, which is a part of 128 bit key encrypting key KEK1 , 

triple encrypted under the master key KM with a control vector C1R. 

e*KM.C2(K) K is a 64 bit key triple encrypted under KM with a control vector C2. 

C2 is the input control vector which is used to recover the key. K is the key being exported. A 1 28 bit key is exported 
20 using two RFMK instructions. 

C1 L.C1 R These are 64 bit control vectors, left and right control vectors for 1 28 bit KEK1 . 

C1 L is the control vector for KEK1L and C1 R is the control vector for KEK1 R key. The actual implementation may 
25 pass only one CV and let the CF set the "key form" bits in the control vector implicitly The CA architecture has chosen 
to pass the left and right control vectors separately for KEKs. CFAP has to generate and manage these two types of 
CVs for the KEKs. 

C2 64 bit input control vector the key K. 

30 

C3 64 bit output control vector for key K. 

- Outputs e*KEK1 .C3(K)K is the 64 bit key being exported. 

35 it can be exported with C3 being a control vector of C3 = 0 control vector. The key K is triple encrypted under 128 

bit KEK1 with control vector C3. In situations where KEK1 L = KEK1 R, the receiver can recover K with a single decryption 
of this output. 

Description: The RFMK instruction re-enciphers a 64 bit key K from encipherment under the master key to enci- 
pherment under a 128 bit key KEK1 (called the EXPORT KEY). A 128 bit key K (i.e., two 64 bit keys) can be exported 
40 by issuing two RFMK instructions. A key exported to a system employing control vectors is encrypted under KEK1 .C3, 
i.e., the control vector accompanies the exported key. A key exported to a system without control vectors is encrypted 
under KEK1.0, i.e., the output control vector specified must be sero. 

RFMK is used to export keys in situations where three or more keys must be distributed (i.e., Genkeyset is incapable 
of generating the required keys). RFMK is also used to ship data/compatability keys to non -control vector systems. If 
45 the dist-mode = 0, then the control vector specified C3 must be zero. Data keys, KEKs, Pin encrypting keys, Pin gen- 
erating keys, intermediate ICV, key parts, and tokens can be shipped to a CV system using RFMK instruction. RFMK 
can't be used to export a GKS created key on CV = 0 channel, this restriction is imposed by the instruction to guarantee 
CV and CV = 0 channel separation. 

Figure 38 is a block diagram for this instruction. 

so 

#CC: 

1 . successful operation 

2. C1 L or C1 R is invalid 
55 3. C2 is invalid 

4. C4 is invalid 

5. unsuccessful operation (error). 
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# Control Vector Checking: 

1 . Checking on C1 L (Export Key): 

-- CV type = "KEK/sender" 

- RFMK usage bit - 1 
reserved(48:63) = X'O' 

2. Checking on C1R (Export Key): 

- CV type = "KEK/sender" 

- RFMK usage bit = 1 

- reserved(48:63) = X'O' 

3. Checking on C2 (Exported Key): 

- CV type = 'data/compatibility" or "data/priv" or "data/mac" or "data/xlt" or "KEK/receiver" or "KEK/sender" 
or "PIN/PEK" or "PIN/PGK" or "KEYPART" or "Intermediate ICV" or "token" 

- reserved(48:63) = X'O' 

4. If dist-mode = 1 then do the following checking: 

- link control (C1L) = "01" or "11" 

- link control (C1R) = "01 n or "1 1 ■ 

- export control bit (C2) = 1 

- CV type (C2) = CV type (C3) 

- usage bits(C2) = usage bits(C3) 

- anti-variant bit 30(C3) = '0' 
anti-variant bit 38 (C3) = 'V 

- reserved(48:63)(C3) = X'O' 

5. If dist-mode = 0 then do the following checking: 

- link control (C1L) = "10" or "11" 
link control (C1 R) = "10° or "11 " 
export control bit (C2) = 1 

- CV type (C2) = "data/compatibility 0 

- C3 = 0 

6. Checking on C1 L & C1 R 

same as specified in Figure 35. 

7. Checking on C3 & C1L.C1R 

- If CV type (C3) = B KEK/sender n or "KEK/receiver" & key form(C3) = '10' or '11' then key form (C1L) = '10' 
&key form (C1R) = '11\ 

Re-encipher To Master Key (RTMK) 



- Equation: dist-mode, e*KM.C1 L(KEK1 L), e*KM.C1 R(KEK1 R), e*KEK1.C3 (K) , C1 L.C1 R.C2.C3 — e*KM.C2 
(K) 

Inputs: dist-mode indicates the channel type used in receiving a key. 
For example CV, CV = 0 channels are used to ship keys. 
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- 0: CV = 0 (channel) 

- 1: CV (channel) 

e*KM.C1l_(KEK1 L) KEK1L is a 64 bit left key encrypting key, which is a part of 128 bit key encrypting key KEK1 , triple 

encrypted under the master key KM with a control vector C1 L. 
e*KM.C1R(KEK1R) KEK1R is a 64 bit right key encrypting key, which is a part of 128 bit key encrypting key KEK1, 

triple encrypted under the master key KM with a control vector C1R. (KEK1 is an input key). 
e*KEK1 C3(K) K is a key shipped from some other node under the key encrypting key (KEK1 ) with a control vector 

C3. 

The key can be shipped single encrypted or triple encrypted, it will be recovered in either case. The key can be 
shipped using a CV channel or CV = 0 channel and the dist-mode must be zero if CV = 0 channel is used. The received 
key may or may not have an odd parity, thus no parity checking is required by CF. C3 is also called an input control vector. 

C1L, C1R These are 64 bit control vectors, left and right control vectors for 128 bit KEK1 . 

C1 L is the control vector for KEK1 L and C1 R is the control vector for KEK1 R key. The actual implementation may 
pass only one CV and let the CF set the "key form" bits in the control vector implicitly. The CA architecture has chosen 
to pass the left and right control vectors separately for KEKs. CFAP has to generate and manage these two types of 
CVs for the KEKs. 

C2 64 bit output control vector for key K. 
C3 64 bit input control vector for key K. 

Outputs: 

e*KM.C2(K) K is a received key, triple encrypted under KM with a control vector C2. 
The key is odd parity adjusted before encrypting with the master key. 

Description: The RTMK instruction re-enciphers a 64 bit key K from encipherment under a 128 bit key encrypting 
key KEK (called the IMPORT KEY) to encipherment under the master key. A 128 bit key K (i.e., two 64 bit keys) can be 
imported by issuing two RTMK instructions. 

A key imported from a system employing control vectors is expected to be encrypted under KEK1 .C3, i.e., the control 
vector accompanies the key to be imported. This is also called importing a key using CV channel. A key imported from 
a system employing no control vectors is expected to be encrypted under KEK1.0, i.e., the control vector is zero. This 
is also called importing a key using CV = 0 channel. There are no other channels available to import or export keys in 
CA systems. The dist-mode must be specified appropriately indicating the channel used to ship the key. For dist-mode 
= 0, the input control vector specified must be zero. CV = 0 can only be used to ship or receive "data/compatibility" keys 
and no other keys can be shipped or received using this channel in CA system. 

The key imported from any system is always encrypted under the master key with a control vector C2, which must 
always be supplied to the instruction, i.e., all keys are stored using the control vector in CA systems. 

Figure 39 is a block diagram for this instruction. 

#CC: 

1 . successful operation 

2. C1L or C1R is invalid 

3. C2 is invalid 

4. C3 is invalid 

5. unsuccessful operation (error). 
# Control Vector Checking: 

- 1 . Checking on C1 L (Import Key): 

- CV type = "KEK/receiver" 

- RTMK usage bit = 1 

- reserved(48:63) = X'O' 
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- 2. Checking on C1R (Import Key): 

- CV type = "KEK/receiver 0 

- RTMK usage bit = 1 

-- reserved(48:63) = X'O' 

- 3. If dist-mode = 1 then do the following checking: 

- link control (C1L) = "01 " or "1 1 " 
-- link control (C1R) = °01 B or "11° 

« CV type = "data/compatibility" or "data/priv" or "data/mac" or "data/xlt" or "KEK/receiver" or "KEK/sender" 

or "PIN/PEK" or "PIN/PGK" or "KEYPART" or "Intermediate ICV" or "token". 
-- reserved(48:63) = X'O' 

- If export control bit (C3) = 0 then export control bit (C2) 
= 0. 

- CV type (C3) = CV type (C2) 

- usage bits(C3) = usage bits(C2) 

- anti-variant bit 30 (C2) = 

- anti-variant bit 38 (C2) = '1 ' 

4. If dist-mode = 0 then do the following checking: 

- link control (C1L) = "10" or "11" 

- link control (C1R) = "10" or "11" 

- CV type (C2) = "data/compatibility" 

- anti-variant bit 30 (C2) = '0' 

- anti-variant bit 38 (C2) = '1 ' 

- C3 = 0 

5. Checking on C1 L & C1 R 

- same as specified in Figure 35. 

6. Checking on C2 & C1 L.C1 R 

- If CV type (C2) = "KEK/sender" or "KEK/receiver" & key form(C2) = '10' or '1V then key form(C1 L) = '10' & 
key form (C1R) = 4 1V. 

Keygen (KGEN) 



Equation: output-type, C1 — K, e*KM.C1(K) 

Inputs: output-type indicates the following output format of the instruction. 

- 0: output 64 bit odd parity adjusted random number (key) 
1 : output 64 bit random number, no parity adjusted 

2: output 64 bit odd parity adjusted random number (key), encrypted under KM with a control vector C1 . 
C1 64 bit control vector for the key generated. 
Outputs: 

K 64 bit clear random number or parity adjusted key. 

e*KM.C1 (K) K is the 64 bit key being generated and triple encrypted under KM with a control vector CI . 

Description: The Keygen function produces a 64 bit odd parity adjusted key or it produces a 64 bit odd parity adjusted 
clear key encrypted under KM with a control vector C1 or a plain 64 bit random number without adjusting the parity. 
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10 



Output-type specifies the type of output required. Keygen instruction can be used to only generate data/compatibility, 
data/priv, data/mac, and data/xlt keys, and ANSI keys. All other key types have to be generated using GKS. 
Figure 40 is a block diagram for this instruction. 

#CC: 

1 . successful operation 

2. C1 is invalid 

3. unsuccessful operation (error). 
# Control Vector Checking: 

1 . Checking on C1 if output-type = 2. 

is - CV type = "data/compatibility" or "data/priv" or "data/mac B or "data/xlt" or "data/ANSP or "ANSI/KEK" 

-- anti-variant(30) = '0' 

- anti-variant(38) = T 

- reserved bits(48:63) = X'O* 

20 Encipher under Master Key (EMK) 



- Equation: K. CI - — e*KM.C1(K) 
25 - Inputs: 

K 64 bit clear odd parity adjusted key supplied to the function or it could be a 64 bit token for a data key. 

The token is stored along with the data key on CKDS. Refer to RTNMK instruction to see the usage of the token 
30 for the data keys. 

C1 64 bit control vector for the key or token supplied. 

- Outputs: e*KM.C1 (K) K is the 64 bit key being supplied and triple encrypted under KM with a control vector C1 . 

35 K can also be a 64 bit token which is stored with the data key on CKDS. 

Description: The encipher under master key instruction produces a 64 bit key or a token encrypted under KM with 
a control vector C1. 

If the key or a token is passed to the function is a "data/priv" or a "token 0 type then it is encrypted under KM with a 
control vector C1. Otherwise, the function can be performed only if the system is in "super secure" mode. In "super 
40 secure" mode this function can encrypt any clear key with any of the CV type. 
Figure 41 is a block diagram for this instruction. 

#CC: 

45 1 . successful completion 

2. C1 is invalid 

3. Not in super secure mode 

4. unsuccessful operation (error). 

50 # Control Vector Checking: 

1. Checking on C1: 

- CV type = "data/compatibility" or "data/priv" or "data/mac" or "data/xlt" or "data/ANSI" or "ANSI/KEK" or 
55 "KEK/sender" or "KEK/receiver" or "token" or "Intermediate ICV" or "PIN/PGK" or "PIN/PEK" 

- anti-variant(30) = '0* 

- anti-variant(38) = T 

-- reserved bits(48:63) = X'0' 
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If (CV type () ("data/compatibility" or "token") then supersecu re-mode-flat = 1 . 
Translate Key (XLTKEY) 

5 



10 



15 



20 



Equation: e*KM.C1 L(KEK1 L), e*KM.C1R(KEKlR), e*KM.C2L(KEK2L), e*KM.C2R(KEK2R), e*KEK1.C3(K), 

mode, C1L, C1R, C2L, C2R, C3 — e*KEK2.C3(K) 

Inputs: 



e*KM.C1L(KEK1L) 

e*KM.C1 R(KEK1 R) 

e*KM.C2L(KEK2L) 

e*KM.C2R(KEK2R) 

e*KEK1.C3(K) 

mode 



KEK1 L is a 64 bit left key encrypting key, which is a part of 128 bit key encrypting key KEK1 , 
triple encrypted under the master key KM with a control vector C1 L (This is an Import KEK). 
KEK1 R is a 64 bit right key encrypting key, which is a part of 1 28 bit key encrypting key KEK1 , 
triple encrypted under the master key KM with a control vector C1 R (This is an Import KEK). 
KEK2L is a 64 bit left key encrypting key, which is a part of 128 bit key encrypting key KEK2, 
triple encrypted under the master key KM with a control vector C2L (This is an Import KEK). 
KEK2L is a 64 bit right key encrypting key, which is a part of 1 28 bit key encrypting key KEK2, 
triple encrypted under the master key KM with a control vector C2R (This is an Import KEK). 
K is a 64 bit key triple encrypted under KM with a control vector C3. K is the key being trans- 
lated, a 1 28 bit key is translated using two XLTKEY instructions. 
0/1 



25 



0: C3 = non-sero control vector 
1:C3 = 0 

C1 L.C1 R These are 64 bit control vectors, left and right control vectors for 128 bit KEK1 . 



C1 L is the control vector for KEK1 L and C1 R is the control vector for KEK1 R key. The actual implementation may 
pass only one CV and let the CF set the "key form" bits in the control vector implicitly. The CCA architecture has chosen 
30 to pass the left and right control vectors separately for KEKs. CFAP has to generate and manage these two types of 
CVs for the KEKs. 

C2L.C2R These are 64 bit control vectors, left and right control vectors for 128 bit KEK2. 
35 C2L is the control vector for KEK2L and C2R is the control vector for KEK2R key. 

C3 64 bit control vector for the key K. 

The same control vector is also used to output the key under KEK2. 

40 

- Outputs: e*KEK2.C2(K) K is the 64 bit translated key. 

Description: The XLTKEY instruction re-enciphers a 64 bit key K from encipherment under the 1 28 bit key encrypting 
key KEK1 (called the IMPORT key) to the 128 bit key encrypting key KEK2 (called the EXPORT key). Locally all KEK's 
45 are 128 bits which are stored under the master key with a control vector. KEKL and KEKR parts of 128 bit KEK are 
encrypted separately under KM to produce two 64 bit encrypted key quantities and stored locally as 1 28 bit concatenated 
quantities. In order to recover 128 bit KEK, there has to be 2 decipherments of type DED operations. A 128 bit key K 
(i.e., two 64 bit keys) can be translated by issuing two XLTKEY instructions. 

Mode parameter specifies the type of the key being translated. The key must be recovered using this mode param- 
50 eter: if mode = 1 then C3 = 0 must be used to recover the key and also translate the key. No mix and match of CV = 0 
with CV is allowed by this instruction. 

Figure 42 is a block diagram for this instruction. 



#CC: 

1 . successful operation 

2. C1L or C1 R is invalid 

3. C2L or C2R is invalid 
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4. C3 is invalid 

5. unsuccessful operation (error). 
# Control Vector Checking: 

- 1. Checking on C1L (Importer Key): 

- CV type = "KEK receiver" 
~ XLATE IN usage bit = 1 

- reserved (48:63) = X*0' 

- 2. Checking on C1R (Importer Key): 

- CV type = "KEK receiver" 

- XLATE IN usage bit = 1 

- reserved (48:63) = X'O' 

3. Checking on C2L (Exporter Key): 

- CV type = "KEK sender" 

- XLATE OUT usage bit = 1 

- reserved (48:63) = X'O' 

4. Checking on C2R (Exporter Key): 

- CV type = °KEK sender": 

- XLATE OUT usage bit = 1 

- reserved (48:63) = X'O' 

5. Checking on C1 L & C2L: 

- As described in Figure 43. 

6. Checking on C1R & C2R: 

- As described in Figure 43. 

7. Checking on C1 L.C1 R.C2L.C2R: 

-- If mode - 0 then 

(link control(C1 L) = (link control(C1 R) = '01 1 or 
(link control(C1 L) = (link control(C1 R) = '1 V 

- If mode = 0 then 

(link control(C2L) = (link control(C2R) = '01 ■ or 
(link control(C2L) = (link control(C2R) = '1 V 

- If mode = 1 then 

(link control(C1 L) = (link control(C1 R) = '10 1 or 
(link control(CIL) = (link control(ClR) = '11' 

- If mode = 1 then 

(link control(C2L) = (link control(C2R) = '10' or 
(link control(C2L) = (link control(C2R) = '11' 
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8. Checking on C3 & C1 L.C1 R 

If CV type (C3) = "KEK/sender D or "KEK/receiver" & key form(C3) = '10' or '1V then 
key form (C1L) = '10* & key form (C1R) = '11'. 

9. Checking on C3 & C2L.C2R 

- If CV type (C3) = "KEK/sender" or "KEK/receiver" & key form(C3) = '10' or '11' then 
key form (C2L) = '10' & key form (C2R) = '11'. 

Re-encipher To New Master Key (RTNMK) 



Equation: 

KEY-MODE mode, e*KMC.C1 (K), C1 e*KMN.C1 (K) 

TOKEN-MODEmode, (token + e*KMC.C1(K)), e*KMC.C2(token), C1, C2 — (token + e*KMN.C1 (K)), e*KMN.C2 
(token) 



Inputs: mode indicates the RTNMK mode as follows: 



0: KEY-MODE 
- 1 : TOKEN-MODE 



Key-mode is used to translate keys into new master keys. Token-mode is used to translate key and token into new 
master key which is stored on DKDS in a special form. CFAP will generate a random number and assign it as a token, 
the encrypted data key e*KM.C1(KD) is exclusive ORed with this token and the resultant value is stored on the DKDS. 
The token itself is a secret quantity, it is encrypted using EMK (e*KM.C2(token)) and also stored on DKDS. When a 
master key is changed the token and the key must be re-enciphered using the RTNMK as an atomic operation. 

e*KMC.C1(K) K is a 64 bit key, triple encrypted under the current master key with a control vector C1 . 

C1 is a control vector for the 64 bit key K. 

(token + e*KMC.C1 (K)) a 64 bit quantity, which is a special quantity stored on DKDS (V operation is an exclusive 

OR). 

CFAP generates this quantity and stores it on DKDs. This input is valid for mode = 1. 
e*KMC.C2(token) a 64 bit token encrypted under the current master key with a control vector C2. 



This is generated using EMK instruction. This input is valid for mode = 1. 



C2 

-Outputs:e*KMN.C1(K) K 
(token + e*KMN.C1(K)) 

e*KMN.C2(token) 



is a control vector for the 64 bit token. This input is valid for mode = 1 . 

a 64 bit key triple encrypted under the new master key with a control vector C1 . 

a special quantity generated under the new master key which can be stored on DKDS. 

This output is valid only for mode = 1 . 

a token re-enciphered under the new master key with a control vector C2. This output 
is valid only for mode = 1 . 



Description: The RTNMK instruction causes a 64 bit encrypted key to be decrypted under the current master key 
and re-encrypted with a new master key. 

RTNMK instruction is used to re-encipher all the keys in the system when a master key is changed. This instruction 
preserves the current master key and new master key in their respective registers in the crypto facility. There should be 
a new master key (NMK) flag to be set in the crypto facility to perform RTNMK instruction. Loading the new master key 
into the crypto facility will set this flag, and at the cut-over point the SMK instruction will reset the NMK flag. There must 
be new master key and current master key facilities in the crypto facility, and there could be additionally an old master 
key location in the CF which contains the previous master key just one level before the current master key. Each master 
key must have a flag associated with it in the CF, and the current master key flag must be set in order to perform the 
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RTNMK operation. The master key flags are set by the SMK instruction at cut-over point. 

In some systems, there may be applications which are offline at the cut-over point. Some keys, therefore, may still 
be encrypted under the old master key. Once the application is online after cut-over, it may translate such keys from the 
old master key to the current master key via the instruction re-encipher to current master key (RTCMK). 

If CMK and NMK flags are not set the operation is aborted. 

The RTNMK instruction can also be used to re-encipher a token and a special value associated with the token in 
one atomic operation. The specific value is an exclusive or of a token and the encrypted data key. The data keys are 
stored on DKDS as this special value and the encrypted value of the token is also stored as a secret quantity. The 
encrypted token value can only be decrypted internal to the RTNMK or RTCMK instructions in the crypto facility. There 
is no other capability of decrypting the token in the CA. The token value is encrypted using EMK and the token is 
associated with a special control vector. The control vector checking is performed in EMK and RTNMK to ensure the 
token's security in the system. 

Figure 44 and Figure 45 are block diagrams for this instruction. 

#CC: 

1 . successful operation 

2. NMK flag not set, illegal sequence 

3. CMK flag not set, illegal sequence 

4. C1 is invalid 

5. C2 is invalid 

6. unsuccessful operation (error). 
# Control Vector Checking: 

1 . Checking on C1 if mode = 0. 

- reserved (48:63) = X'O' 

2. Checking on C2 if mode = 1 . 

- CV type = "token" 

- reserved (48:63) = X'O* 

Re-encipher To Current Master Key (RTCMK) 



Equation: 

KEY-MODE mode, e*KMO.C1 (K), C1 - — e*KMC.C1 (K) 

TOKEN-MODEmode, (token + e*KMO.C1 (K)),e*KMO.C2(token), C1, C2 - — (token + e*KMC.C1(K)),e*KMC.C2 
(token) 

Inputs: mode indicates the RTCMK mode as follows: 

0: KEY-MODE 
~ 1 : TOKEN-MODE 

e*KMO.C1(K) K is a 64 bit key, triple encrypted under the old master key with a control vector C1 . 

C1 is a control vector for the 64 bit key K. 

(token + e*KMO.C1(K)) a 64 bit quantity, which is a special quantity stored on DKDS (V operation is an ex- 
clusive OR). 

CFAP generates this quantity and stores it on DKDS. This input is valid for mode = 1 . 
e*KMO.C2(token) a 64 bit token encrypted under the old master key with a control vector C2. 
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This is generated using EMK instruction. This input is valid for mode = 1 . 

C2 is a control vector for the 64 bit token. This input is valid for mode = 1 . 

- Outputs:e*KMC.C1 (K) K a 64 bit key triple encrypted under the current master key with a control vector C1 . 
5 (token + e*KMC.C1(K)) a special quantity generated under the current master key which can be stored on DKDS. 

This output is valid only for mode = 1 . 
e*KMC.C2(token) a token re-enciphered under the current master key with a control vector C2. This output 

is valid only for mode = 1 . 

10 Description: The RTCMK instruction causes a 64 bit encrypted key to be decrypted under th old master key and 

re-encrypted with a current master key. 

RTCMK instruction is used to re-encipher the keys in the system which were encrypted under the old master key 
and since then the master key has been changed. That is, the NMK flag is not set and SMK instruction has been already 
executed. The current master key is the new master key for the keys which were not translated using RTNMK. In order 

is the execute this instruction, the CMK flag and OMK flags must be set and the NMK flag must be reset in the CF. This 
instruction preserves the current master key and new master key in their respective registers in the crypto facility. 

CFAP in the crypto subsystem must be aware of the usage of RTNMK and RTCMK instructions and the level of the 
master key. Only one level previous to the master key can be optionally maintained in the CF to solve the old master 
key problem and the CFAP has to keep track of the keys encrypted under the old master key and the current master key. 

zo RTCMK instruction is an optional instruction which can be implemented only if one wants to do RTCMK after the 

cutover point of the new master key. 

If OMK and CMK flags are not set and NMK flag not reset then the operation must be aborted. 
The RTCMK instruction can also be used to re-encipher a token and a special value associated with the token in 
one atomic operation. The special value is an exclusive or of a token and the encrypted data key. The data keys are 

25 stored on DKDS as this special value and the encrypted value of the token is also stored as a secret quantity. The 
encrypted token value can only be decrypted internal to the RTNMK or RTCMK instructions in the crypto facility. There 
is no other capability of decrypting the token in the CA. The token value is encrypted using EMK and the token is 
associated with a special control vector. The control vector checking is performed in EMK and RTCMK to ensure the 
token's security in the system. 

30 Figure 46 and Figure 47 are block diagrams for this instruction. 

#CC: 

1 . successful operation 
35 2. OMK flag not set, illegal sequence 

3. CMK flag not set, illegal sequence 

4. NMK flag not reset, illegal sequence 

5. C1 is invalid 

6. C2 is invalid 

<o - 7. unsuccessful operation (error). 

# Control Vector Checking: 

1 . Checking on C1 if mode = 0. 

45 

- reserved (48:63) = X'O* 

2. Checking on C2 if mode = 1 . 

so - CVtype = token" 

- reserved (48:63) = X'O' 

Set Master Key (SMK) 



55 



Equation: () 
Inputs: none 
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Outputs: none 

Description: The SMK instruction causes the following: 

5 - 1 . (old master key = current master key) 

2. (old master key flag = 1 ) 

3. current master key = new master key 

4. current master key flag = 1 

5. new master key flag = 0. 

10 

This instruction must only execute in "super secure" mode, i.e., the physical key position must be In "super secure" 
position an in the crypto facility super secure flag must be set to execute this instruction. The left and right parts of the 
master key is checked for non- equality from the new master key register and operation must be aborted if the two parts 
are equal. 

15 After SMK is executed in the CF, the CF from now on will use the new master key for all the crypto operations. The 

cutover point is in effect after execution of this instruction. If there are more keys in the system which are encrypted 
under the old master key, then the optional instruction RTCMK is the only way to re-encipher the keys. 
If NMK flag is not set in the CF, the operation must be aborted. 

20 # CC: 



1 . successful operation 
25 - 2. NMK flag not set 

3. left and right parts are equal 

4. super secure flag not set, invalid sequence 

5. unsuccessful operation (error). 

30 ** MDCOP " 

DESCRIPTION: An instruction within the skill of the art which calculates a Modification Detection Code (MDC). 
CLeaR Crypto Facility (CLRCF) 

35 



Equation: () 
Inputs: none 
40 - Outputs: none 

Description: Crypto facility (CF) registers, flags and all the local memory are cleared. This function can be used to 
clear the master keys and flags if the master key is compromised. If the master keys flags are reset, the intruder cannot 
execute RTNMK or RTCMK to translate the keys from the compromised key to his own master key. 
45 This function may be implemented under the control of a physical key or as a privileged instruction, depending on 

the degree of protection desired to prevent loss of service from unauthorised users. 

#CC: 

50 

1 . successful operation 

2. unsuccessful operation (error). 

55 CLeaR Key Part Register (CLRKPR) 
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Equation: () 
Inputs: none 
Outputs: none 

5 Description: This instruction clears the key part register in the crypto facility (CF). This instruction may be used to 

clear an erroneous or compromised entry in the key part register. CLRKPR permits clearing the key part register without 
disrupting the entire CF; however, CLRCF instruction may also be used. It is up to the implementer how he chooses to 
implement the instruction CLRCF and CLRKPR; for example, there could be a single instruction which can selectively 
reset a CF register. A given implementation may use a physical key or as a privileged instruction, depending on the 

10 degree of protection desired to prevent loss of service from unauthorised users. 



#CC: 



15 

1 . successful operation 

2. unsuccessful operation (error). 

CLeaR NMK register (CLRNMK) 

20 



Equation: () 
Inputs: none 
25 - Outputs: none 

Description: This instruction clears the NMK register in the crypto facility (CF). If the NMK entered erroneously into 
the CF or the NMK is compromised then this instruction can be used. Clear crypto facility instruction is too general to 
use and thus this instruction can be used to clear a new master key register. It is up to the implementer how he chooses 
30 to implement the instructions like CLRCF CLRKPR and CLRNMK, for example, there could be a single instruction which 
can selectively reset a CF register. A given implementation may use a physical key or as a privileged instruction, de- 
pending on the degree of protection desired to prevent loss of service from unauthorised users. 



#CC: 

35 



1 . successful operation 

2. unsuccessful operation (error). 

40 

Lower CV Authority (LCVA) 



45 - Equation: e*KM.C1 (K),C1 ,C2 — - e*KM.C2(K) 
Inputs: 

e*KM.C1 (K) K is a 64 bit key, triple encrypted under the master key with a control vector C1 . 
C1 64 bit input control vector. 

50 02 64 bit output control vector. 

Outputs: e*KM.C2(K) K is a 64 bit key triple encrypted under KM with a 64 bit control vector C2. 

Description: LCVA is a control vector instruction is architected for lowering authority on the export control field in 
55 the CV. 

#CC: 
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1 . successful operation 

2. C1 or C2 is invalid 

3. unsuccessful operation (error). 

# Control Vector Checking: 

1 . Checking on C1 and C2. 

CV type(C1 ) = CV type(C2) 
-- reserved (48:63)(C1) = reserved (48:63)(C2) = X'O' 
Usage bits for KEKs (C1 ) = Usage bits for KEKs (C2) 

- Usage bits for PIN keys(C1 ) = Usage bits for PIN keys(C2) 

- Export Control Bits: 

export control bit 1 (C2) = 1 (no further RFMK) 

Load First Master Key Part (LFMKP) 



Equation: () 
Inputs: none 
Outputs: none 

Description: This instruction transfers the content of the KP register to the NMK register - Flag(NMK Reg) = "partially 
full" and flag(KP Reg) = "Empty". It loads the first part of the master key stored in the Key Part register into the NMK 
(New Master Key) register. Also, the flag of the NMK Reg is set to "partially full" state (from the "empty 0 state) to indicate 
that the NMK Register is not complete, and the content of the Key Part register is set to "Empty" state (from the "full- 
state) to indicate that the Key Part register is now empty. This operation is performed only if the Key Part register is now 
in the "full" state and the NMK register is in the "empty" state. 

NOTE: It is assumed that prior to the execution of this instruction, the first master key part has been brought into 
the Key Part register by a key-entry device (such as a key pad) or a key board, with a triggering button (e.g., "Enter 
key"). (The triggering button is usually employed to initiate the action of loading the value of the key entered via the key 
pad or key board into the Key Part register). 

The following additional feature is optional, can be implemented on systems that have physical key(s): 

For this instruction to be carried out, beside the requirement on the flags of the registers as mentioned above, the 
key switch position is sensed and it must be in an appropriate position (e.g., first master key part enable). 

#CC: 

1 . successful operation 
- 2. CKP1 is not valid 

3. unsuccessful operation (error). 

# Control Vector Checking: None 

Combine Master Key Parts (CMKP) 



Equation: mode ===== Content of NMK = (Content of NMK Reg) XOR (Content of KP Reg), flag(KP Reg) = "Empty" 
and flag(NMK) = "Partially full" if mode = 0 or flag(NMK) = "full" if mode = 1 . 
Input: none 
Output: none 

Where mode is the input of the instruction, indicating whether the master key part to be combined is the last key 
part or not. 

If mode = 0 then the master key part to be combined is not the last key part, and more key parts are expected to 
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be combined later to form the complete master key. 

- If mode = 1 then the master key part to be combined is the last key part, and the complete new master key is to be 
formed in the NMK reg after the execution of this instruction. 

5 Description: This instruction XORs the jth master key part KPj stored in the Key Part register with other Key Part(s) 

stored in the NMK register, and stores the result in the NMK register. 
The instruction also: 

- Sets the flag of KP Reg to the "Empty" state (from the "full" state) 

io - Sets the flag of the NMK Reg to the "full" state if mode = 1 , or to the "partially full" state if mode = 0. 

This instruction is performed only if the Key Part register is in the "full" state and the NMK register is in the "partially 
full" state. 

Note: It is assumed that prior to the execution of this instruction, the master key part KPj has been brought into the 
15 Key Part register by a key-entry device (such as a key pad) or a key board, with a triggering button (e.g., "Enter key"). 
(The triggering button is usually employed to initiate the action of loading the value of the key entered via the key pad 
or key board into the Key Part register). 

The use of this instruction and the Load first master key part instruction in the installation of a master key of multiple 
parts (e.g., a master key KM may have n parts KM1, KM2,... KMn such that KM = KM1 XOR KM2 ... XOR KMn) is 
20 described in the key installation procedures of the Key management section. 

The following additional feature is optional, can be implemented on systems that have physical key(s): 

For this instruction to be carried out, beside the requirement on the flags of the registers as mentioned above, the 
key switch position is sensed and it must be in an appropriate position (e.g., second master key part enable position). 

2s # CC: 

1 . successful operation 

2. Ckp1 or Ckp2 or Ckek is not valid. 

3. unsuccessful operation (error). 

30 

# Control Vector Checking: 
None. 

35 Load First Key Part (LFKP) 

DESCRIPTION: This instruction encrypts the first key part of a key that has been stored in the Key Part register. 
The encrypted key part is then stored in the key storage by CFAP for later retrieval and combining (by the Combine Key 
Part instruction) with other key parts of the key. Execution of this instruction also sets the flag of the Key Part register 
40 from the "full" state to the "empty" state. 

For this operation to be carried out, the Key Part register must be in the "full" state. 

Combine Key Parts (CKP) 

45 DESCRIPTION: The Combine Key Part instruction combines a key part stored in the Key Part register with the 

previous key part of a key. The combining of the key parts are done by XORing them together. Execution of this instruction 
also sets the flag of the Key Part register to the "empty" state (from the full state). 

This instruction is carried out only if the flag of the Key Part register is in the "full" state. 

so Compute Verification Pattern (CVP) 

DESCRIPTION: The CVP instruction computes a verification pattern on a given key K. The verification pattern may 
be used to verify if a manually installed key is entered correctly. Details of the instruction are outside the scope of the 
invention. 

55 

ANSI Generate Error Detection Code (AGEDC) 
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Equation: A ===== EDC 

Inputs: A Data for which Error Detection Code is to be generated. 

Outputs: EDC 64 bit Error Detection Code computed for the data specified by A. 

s Description: Error Detection Codes are used in ANSI X9. 17-1 985 to detect transmission errors or process errors 

when other means (such as authentication under a secret key) is unavailable. The EDC is generated using the authen- 
tication technique (MAC) defined in ANSI X9.9-1982 and a fixed, non-secret key KDX = X"0 123456789 ABC DEP. 

AGEDC may be simulated in CFAP using the ENCODE instruction and the clear value KDX. This instruction should 
NOT be simulated using other CA instructions (e.g., GMAC or ENCIPHER) with a pre-computed form of KDX encrypted 

10 under the master key (since it represents a known value encrypted under the master key). 

ANSI Verify Error Detection Code (AVEDC) 



15 

Equation: A, EDC ===== yes/no 
Inputs: 

A Data to be verified against supplied Error Detection Code. 
20 EDC 64 bit Error Detection Code to be verified for the data specified by A. 

Outputs: yes/no indicates that the Error Detection Code computed on data specified by A matches the 
supplied EDC. 

25 Description: Error Detection Codes are used in ANSI X9. 17-1 985 to detect transmission errors or process errors 

when other means (such as authentication under a secret key) is unavailable. The EDC is generated using the authen- 
tication technique (MAC) defined in ANSI X9.9-1982 and a fixed, non-secret key KDX = X'0 123456789 ABC DEP. 

AVEDC may be simulated in CFAP using the ENCODE instruction and the clear value KDX. This instruction should 
NOT be simulated using other CA instructions (e.g., GMAC or VMAC) with a pre-computed form of KDX encrypted under 

30 the master key (since it represents a known value encrypted under the master key). 

ANSI create Partial NOTaRising key (APNOTR) 



35 

- Equation: mode,e*KM.C1 L(KK1 ),e*KM.C1 R(KKr), FMID, TOID, C1L.C1 R, C2L.C2R ==== e*KM.C2L 
(KKNIL),e*KM.C2R(KKNIR) 

- lnputs:mode indicates whether the input *KK = KK1 //KKr is a replicated 64 bit (KK1 = KKr) or true 128 bit KEK. 

40 - 0: true 128 bit KEK 

- 1: replicated 64 bit KEK 

The algorithm for creating partial notarising keys differs slightly for 64 bit KEKs and 1 28 bit KEKs (see "Notarisation 
Algorithms"). The Mode parameter selects the correct algorithm since the correct choice cannot be inferred from the 
45 input KEK itself (i.e., both 64 bit KEKs and 128 bit KEKs are input as 128 bits.) 

e*KM.C1L(KK1) 64 bit KK1 encrypted under the master key with a control vector C1L. KK1 is the left part of a 128 bit 
key encrypting key *KK. 

e*KM.C1R(KKr) 64 bit KKr encrypted under the master key with a control vector C1R. KKr is the right part of a 128 
so bit key encrypting key *KK. 

NOTE: In CA, all KEKs (including ANSI KEKs) are stored in 128 bit form, as left and right 64 bit parts. (64 bit KEks 
are replicated to form 1 28 bits. In this case, the left and right parts are equal.) The left part of the *KK is encrypted under 
the master key with a left control vector and stored on CKDS. Similarly, the right part of the *KK is encrypted under the 
55 master key with a right control vector and stored on CKDS. Key form bits in the control vector differentiate between left 
and right parts and between 64 or 128 bit KEKs. 

FMID 16 ASCII characters as defined in ANSI X3.4-1977. 
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This is a "from" node ID which is used as a notarisation parameter. If the ID is not 16 characters then the ID must 
be repeated until 16 characters are formed as described in Section 7.5 of ANSI X9. 17-1 985, "Notarisation of Keys." 
(See "References"). 

s TOID 16 ASCII characters as defined in ANSI X3.4-1977. 

This is a "to" node ID which is used as a notarisation parameter. If the ID is not 16 characters then the ID must be 
repeated until 16 characters are formed as described in Section 7.5 of ANSI X9. 17-1 985, "Notarisation of Keys." (See 
"References"). 

w 

C1 L.C1R 64 bit control vectors for left and right part of *KK respectively. 

C2L.C2R 64 bit control vectors for left and right part of *KKNI respectively. 

- Outputs: e*KM.C2L(KKNIL) 64 bit KKNIL encrypted under the master key with a control vector C2L. 

is This is the left part of 128 bit *KKNI which is a partial, or Intermediate, Notarising form of the input KEK, *KK. A 

'partial' notarising key is a notarising key which has not been offset. Offsetting must be performed on *KKNI prior to 
using it as a notarising key for the import or export of notarised keys. Offsetting is implicitly performed by ARTMK, 
ARFMK, and AXLTKEY. 

20 e*KM.C2R(KKNIR) 64 bit KKNIR encrypted under the master key with a control vector C2R. 

This is the right part of 128 bit *KKNI which is a partial notarising form of the input KEK, *KK. 
NOTE: All KEKs and partial notarising KEKs are stored in 128 bit form in CA. 

Description: ANSI Notarisation is a method for sealing keys with the identities of the communicating pair, that is, 
25 the sender the receiver of the keys. Once notarised, keys can only be recovered with knowledge of the original key 
encrypting key and the identities of the communicating pair. A data key or key encrypting key may be notarised before 
transmission by encrypting using a Notarising Key (*)KN. 

In ANSI, (*)KN is formed by exclusive-ORing a KEK (*)KK with a notary seal NS, which is composed of the identity 
of the key sender, the identity of the intended key recipient, and the current value of a key-message counter associated 
30 with (*)KK. Note that the (*)KN must be recomputed for each transmission, since the counter value is a dynamic quantity, 
i.e., it increments with each use of (*)KK. 

In CA, the process of forming (*)KN has been divided into two separate steps. APNOTR is called first to compute 
an intermediate form of (*)KN, denoted *KKNI, which is based just on the static quantities of NS, namely the identity of 
the sender, the identity of the intended recipient, and (*)KK itself. The final step, known as Offsetting, combines *KKNI 
35 and the current counter value associated with (*)KK to form (*)KN. The reason for splitting the formation of (*)KN in CA 
into two steps is two-fold: 

1 . Efficiency. Since (*)KN is composed of three static quantities (the two pair identities and (*)KK itself) and only 
one dynamic quantity (the counter associated with (*)KK) there is no need to recompute (*)KN completely every 

40 time the (*)KK-counter is updated. The process of forming (*)KN can therefore be divided into a one-time event 

using the static quantities and a simpler, repeated event using the dynamic quantity. 

2. Transparency. In ANSI, ALL KEKs must be offset prior to using them to encrypt a key (KD or (*)KK) for transmis- 
sion, whether notarisation is used or not. Thus, offsetting was included as an implicit operation in all CA ANSI 

45 instructions which use a KEK to encrypt or decrypt another key, namely ARTMK, ARFMK, and AXLTKEY. By dividing 

the (*)KN formulation in the prescribed manner, notarisation becomes transparent to the instructions ARTMK, AR- 
FMK, and AXLTKEY. 

APNOTR is used to generate a partial notarising key *KKNI for a given KEK. Partial notarising keys are used when- 
50 ever a notarised key (KD or (*)KK) is to be imported via ARTMK, translated via AXLTKEY, or exported via ARFMK. For 
example, suppose a data key DK1 is to be translated from encryption under an offset KEK, *KK1 , to encryption under 
the notarising form of another KEK, *KK2. APNOTR is called with *KK2 and the identities of the caller and the intended 
recipient to create *KKNI1, the partial notarising form of *KK2. *KK1 and *KKNI2 are then passed to AXLTKEY as the 
input and output KEKs, respectively. AXLTKEY offsets *KK1 and *KKNI2 with their respective counter values and uses 
55 the resulting KEKs to recover KD1 internally and re-encipher it for output. (Note that APNOTR need only be called once 
for *KK2; *KKNI2 could be saved on CKDS (Key Storage) for subsequent use whenever notarisation is desired. However, 
it is up to the implementer whether APNOTR is done dynamically or once for each (*)KK with this key management 
approach.) Using this same example, if notarisation und *KK2 had not been required, *KK1 and *KK2 could have been 
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passed directly to AXLTKEY for offsetting, recover, and re-encipherment of KD1. 

Offsetting is always implied in the use of all ANSI KEKs so the offset function is imbedded in the hardware and 
implicitly performed by the ARTMK, ARFMK, and AXLTKEY instructions in the crypto facility. This method avoids a 
separate instruction for Offset and facilitates the transparency of notarising keys to these functions. APNOTR was de- 
signed to improve notarisation performance assuming that there is a separate (*)KK shared between each pair of com- 
municating nodes and the node IDs do not change. 

The partial notarising key formation algorithm is shown in Figure 48 and Figure 49. The algorithm was designed to 
exploit the steps in common between the separate algorithms for single length and double length KEKs. If the input KEK 
and output partial notarising KEK are treated as 128 bits, then the only difference is in the formation of the quantities 
NSI and NSr, which are exclusive-ORed with the input KEK to form *KKNI. The Mode parameter, which indicates the 
actual key size of the input KEK, controls the formation of NSI and NSr. A MUX, under the control of Mode, selects one 
of two 32 bit inputs to use in forming the right half of NSI. Likewise a MUX selects one of two inputs to use in forming 
the left half of NSr. The selection process is shown in Figure 49. Use of the Mode parameter and MUXs permits the 
formation of a *KKNI which is independent of the actual key size of the input *KK, is equivalent to the notarising key 
defined in ANSI X9.17 (after offsetting), and is storage compatible with other CA ANSI KEKs. 

The input to APNOTR is always a 128 bit KEK; the output is always 128 bits. If APNOTR is passed a replicated 64 
bit KEK, then the Mode parameter must be set to 1 , and APNOTR returns a replicated 64 bit partial notarising KEK on 
output. The Key Form fields of C1 L, C1 R, C2L, and C2R must be consistent with the value of the passed Mode parameter 
(see CV Checking below). Partial notarising keys cannot be re-input to APNOTR. This aspect of the key management 
design is enforced via the hardware checking on control vectors C1L, C1 R, C2L, and C2R, left 64 bits and right 64 bits 
of *KKNI, and is invoked once to create a partial notarising key. This is in contrast to other CA functions which require 
an invocation for each 64 bit part of a 1 28 bit KEK. 

#CC: 

1 . successful operation 

2. C1L or C1R is invalid 
- 3. C2L or C2R is invalid 

4. unsuccessful operation (error). 

# Control Vector Checking: 
- 1. Checking on C1L: 

- CVtype = n KEK/ANSr 

- APNOTR Usage bit = '1 ' 

- key form (C1 L) = key form (C2L) 
-- reserved (48:63) = X'O' 

- 2. Checking on C1R: 

- CV type = n KEK/ANSI 0 

- APNOTR Usage bit = T 

- key form (C1 R) = key form (C2R) 

- reserved (48:63) = X'O' 

3. Checking on C2L: 

-- CV type = 0 KEK/ANSI" 
APNOTR Usage bit = '0' 

- reserved (48:63) = X'O' 

4. Checking on C2R: 

- CVtype = fl KEK/ANSI° 

- APNOTR Usage bit = '0' 

- reserved (48:63) = X'O' 
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ANSI Re-encipher From Master Key (ARFMK) 

5 

- Equation: e*KM.C1 L(KKL),e*KM.C1 R(KKR), e*KM.C2(K),cntr, key-type, C1L, C1R, C2, (C3) ===== e*KKo(K), 
e*KM.C3(K) (key-type = 0, data key) 

or 

10 e*KKo(K) (key-type = 1 , KEK) 

Inputs: 

e*KM.C1 L(KKL) left 64 bits of *KK, denoted KKL, encrypted under the master key with a control vector C1 L. *KK 
is a 128 bit key encrypting key or partial notarising key. 
15 e*KM.C1 R(KKR) right 64 bits of *KK, denoted KKR, encrypted under the master key with a control vector C1 R. 

*KK is a 128 bit key encrypting key or partial notarising key. 

NOTE: In CA, all KEKs (including ANSI KEKs) are stored in 128 bit form, as left and right 64 bit parts. (64 bit KEKs 
are replicated to form 1 28 bits. In this case, the left and right parts are equal.) The left part of the *KK is encrypted under 
20 the master key with a left control vector and stored on CKDS. Similarly, the right part of the *KK is encrypted under the 
master key with a right control vector and stored on CKDS. Key form bits in the control vector differentiate between left 
and right parts and between 64 or 128 bit KEKs. 

e*KM.C2(K) 64 bit ANSI key K to be exported; K is triple encrypted under the master key with a control vector C2. 

25 

This key can be a data key, a 64 bit key encrypting key, or the left or right half of a 1 28 bit key encrypting key. 

cntr 64 bit clear send-counter value associated with key encrypting key *KK. 

30 This value is ordinarily transmitted along with the exported key to the intended recipient. The recipient uses the 

received counter to detect replay, to synchronise its local receive -counter for *KK, and to recover the exported key. Local 
counters are maintained by the CFAP with integrity. 

key-type the type of key to be exported. 

35 

NOTE: For a data key the encrypted output of ARFMK is in two forms. One form of output is for export to the intended 
recipient; the key is encrypted under an offset form of the specified key encrypting key. The other form can either be 
used directly to MAC CSMs (in the case where a single KD is to be exported) or can be later combined with another 
such key to form a CSM MAC key (in the case where two KDs are exported at a time). ACOMBKD instruction is used 
40 to combine these 'partial' MAC keys into a CSM MAC key. 

-- 0: KD 

- 1:KK 

45 C1 L,C1 R 64 bit control vectors for the left and right parts respectively of the key encrypting key or 

partial notarising key *KK. 
C2 64 bit control vector for the input key K. 

C3 64 bit control vector for the CSM MAC key or partial CSM MAC key to be stored under 

KM. This input is only valid when key-type = 0. 
so - Outputs: e*KKo(K) 64 bit key K triple encrypted under key encrypting key or notarising key *KKo, where 

*KKo is *KK offset with cntr. 

If *KK is a partial notarising key, denoted *KKNI, then *KKo is a notarising key, denoted *KN, and K is the to be 
'notarised.' 

55 

e*KM.C3(K) 64 bit data key K triple encrypted under the master key KM with a control vector C3. 

This output is valid only for key-type - 0 and is either used directly to MAC CSMs or is combined via ACOMBKD 



64 



EP 0 356 065 B1 



with another such key to MAC CSMs. 

cntr 64 bit clear send-counter value associated with key encrypting key *KK. 

5 This value is ordinarily transmitted along with the exported key to the intended recipient. The recipient uses the 

received counter to detect replay, to synchronise its local receive=counter for *KK, and to recover the exported key. 
Local counters are maintained by the CFAP with integrity. 

key-type specifies the type of key to be exported. 

10 

NOTE: For a data key the encrypted output of ARFMK is in two forms. One form of output is for export to the intended 
recipient; the key is encrypted under an offset form of the specified key encrypting key. The other form can either be 
used directly to MAC CSMs (in the case where a single KD is to be exported) or can be later combined with another 
such key to form a CSM MAC key (in the case where two KDs are exported at a time). ACOMBKD instruction is used 
is to combine these 'partial' MAC keys into a CSM MAC key. 

- 0: KD 

- 1: KK 

20 C1 L.C1 R 64 bit control vectors for the left and right parts respectively of the key encrypting key or 

partial notarising key *KK. 
C2 64 bit control vector for the input key K. 

C3 64 bit control vector for the CSM MAC key or partial CSM MAC key to be stored under 

KM. This input is only valid when key-type = 0. 
25 - Outputs: e*KKo(K) 64 bit key K triple encrypted under key encrypting key or notarising key *KKo, where 

*KKo is *KK offset with cntr. 

If *KK is a partial notarising key, denoted *KKNI, then *KKo is a notarising key, denoted *KN, and K is the to be 
'notarised'. 

30 

e*KM.C3(K) 64 bit data key K triple encrypted under the master key KM with a control vector C3. 

This output is valid only for key-type = 0 and is either used directly to MAC CSMs or is combined via ACOMBKD 

with another such key to MAC CSMs. 
35 Description: ARFMK instruction re-enciphers a 64 bit key K from encipherment under the master key to encipherment 

under a 128 bit or replicated 64 bit key encrypting key *KK (called the EXPORT KEY). A 128 bit key K can be exported 

by invoking ARFMK twice, once for each 64 bit half; however, *KK must be a true 128 bit KEK in this case. This rule is 

enforced by hardware (see CV checking below). 

ARFMK may be used to export keys in either notarised or non-notarised form in accordance with ANSI X9.1 7. ANSI 
40 keys may be export in non-notarised form by invoking ARFMK with a key encrypting key shared with the intended 

recipient. ARFMK internally performs offsetting on the specified key encrypting key. ANSI keys may be export in notarised 

form by invoking ARFMN with the partial notarising form of a key encrypting key shared with the intended recipient. 

ARFMK internally performs offsetting on the specified partial notarising key to create the notarising key. Partial notarising 

keys are formed from key encrypting keys by the APNOTR instruction. 
45 For example, let *KKab be a key encrypting key shared by nodes A and B. Let *KKNIab be a partial notarising key 

formed from *KKab by invoking APNOTR. Then key K may be exported from A to B in non-notarised form by invoking 

ARFMK with *KKab as the key encrypting key. Key K may be exported from A to B in notarised form by invoking ARFMK 

with *KKNIab as the key encrypting key. 

In ANSI X9.17, one or two KDs may be exported in a single CSM. If one KD is shipped, it may be ultimately used 
50 as either a privacy key or MAC key. The CSM itself is authenticated with the shipped KD. If two KDs are shipped, the 

first KD is a MAC key and the second is a privacy key. The CSM is authenticated with the exclusive-OR of the two KDs. 
ARFMK supports CSM authentication by outputting exported data keys in two forms. The first form of the KD is for 

export, i.e., encrypted under an offset form of the specified key encrypting key. The second form of the KD may be used 

operationally to directly MAC the CSM (as in the case of a single KD above), or may be combined (exclusive-ORed) 
55 with another KD of this form to create a key to MAC the CSM. The latter usage corresponds to the case of two KDs in 

a single CSM. Parameter C3 controls whether the second output form is a MAC key or 'partial' MAC key. the ACOMBKD 

is used to combine partial MAC keys from two ARFMK invocations into a single CSM MAC key. 
Figure 50 shows the ARFMK functional block diagram. 
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#CC: 

1 . successful operation 

2. C1LorC1Ris invalid 

3. C2 is invalid 

4. unsuccessful operation (error). 
# Control Vector Checking 

- 1. Checking on C1L: 

- CV type = "KEK/ANSl" 
-- ARFMK Usage bit = T 
-- reserved (48:63) = X'O' 

2. Checking on C1R: 

- CV type = "KEK/ANSl" 

- ARFMK Usage bit = T 

- reserved (48:63) = X'O 1 

3. Checking on C2: 

- CV type = "KEK/ANSI" or "data/ANSI" 

- export control bit 1 = 0 (RFMK allowed) 

- If CV type = "data/ANSI" then do the following checking: 

— Figure 51 shows the valid combinations of C2 attributes which must be checked. Any combination 
other than those in the table is cryptographically invalid and thus must not be allowed E, D, MG, MV, 
ACMB are the usage bits for the data key control vector. 

4. Checking on C2 & C1 L,C1 R: 

~ Figure 52 shows the valid combinations of C2 type and Key Form versus C1 L and C1 R Key Form attributes. 
These attributes are checked to enforce left versus right half separation and to ensure that a true 128 bit 
KEK may only be exported under a 128 bit KEK. Any other combinations of these attributes other than 
those in this table are cryptographically invalid and thus must not be allowed. 

5. Checking on C3: 

- CV type = "data/ ANSI" 
-- reserved (48:63) = X'O' 

- export control bit 1=1 (no export) 

- Figure 53 shows the valid combinations of C3 attributes which must be checked. Any combination other 
than those in the table is cryptographically invalid and thus must not be allowed. E, D, MG, MV, ACMB are 
the usage bits for the data key control vector. 

ANSI Re-encipher To Master Key (ARTMK) 



- Equation: e*KM.C1 L(KKL), e*KM.C1 R(KKR), e*KKo(K), cntr, key-type, C1L,C1R,C2,(C3) ==== e*KM.C2(K), 
e*KM.C3(K) (key-type = 0, data key) 
or 

e*KM.C2(K) (key-type = 1 , KEK) 

Inputs: e*KMC1 L(KKL) left 64 bits of *KK, denoted KKL, encrypted under the master key with a control vector 
C1L. 
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*KK is a 1 28 bit key encrypting key or partial notarising key. 
e*KM.C1 R(KKR) right 64 bits of *KK, denoted KKR, encrypted under the master key with a control vector C1 R. 

5 *KK is a 1 28 bit key encrypting key or partial notarising key. 

NOTE: In CA, all KEKs (including ANSI KEKs) are stored in 128 bit form, as left and right 64 bit parts. (64 bit KEKs 
are replicated to form 1 28 bits. In this case, the left and right parts are equal.) The left part of the *KK is encrypted under 
the master key with a left control vector and stored on CKDS. Similarly, the right part of the *KK is encrypted under the 
master key with a right control vector and stored on CKDS. Key form bits in the control vector differentiate between left 

10 and right parts and between 64 or 1 28 bit KEKs. 

e*KKo(K) 64 bit ANSI key K to be imported; K is triple encrypted under key encrypting key or notarising key *KKo, 
where *KKo is *KK offset with cntr. 

15 if *KK is a partial notarising key, denoted *KKNI, then *KKo is a notarising key, denoted *KN, and K is the to be 

notarised. Note that if *KK is a replicated 64 bit key, i.e. *KK = KK//KK, then e*KKo(K) is equivalent to eKKo(K), an ANSI 
key K singly encrypted under an offset 64 bit key. 

cntr 64 bit clear counter value associated with the key encrypting key *KK. 

20 

This value is ordinarily supplied by the key sender and represents the counter used to offset *KK before encrypting 
K. Cntr should be compared with the corresponding local receive-counter for *KK in accordance with ANSI X9. 1 7 Counter 
Management before invoking ARTMK to import the received key. The comparison step and ARTMK-invocation step 
should be performed atomically within CFAP to preserve integrity. The local counters are maintained by the CFAP with 
25 integrity. 

key-type specifies the type of key to be imported. 

NOTE: For a data key the encrypted output of ARTMK is in two usable forms. One form of output is for the ultimate 
30 usage of the imported key; it can be used as a privacy key or MAC key. The other form can either be used directly to 
MAC CSMs (in the case where a single KD is to be imported) or can be later combined with another such key to form 
a CSM MAC key (in the case where two KDs are imported at a time). ACOMBKD instruction is used to combine these 
'partial' MAC keys into a CSM MAC key. 

35 - 0: KD 

- 1:KK 

C1L.C1R 64 bit control vectors for the left and right parts respectively of the key encrypting key or partial notarising 
key *KK. 

40 C2 64 bit control vector for the key K to be stored under KM. 

This control vector specifies the ultimate intended usage of the imported key K. 
C3 64 bit control vector for the CSM MAC key or partial CSM MAC key to be stored under KM. 

45 

This input is only valid when key-type = 0. 

- Outputs: e*KM.C2(K) 64 bit received key K triple encrypted under the master key KM with a control vector C2. 
e*KM.C3(K) 64 bit received data key K triple encrypted under the master key KM with a control vector 

50 C3. 

This output is valid only for key-type = 0 and is either used directly to MAC CSMs or is combined via ACOMBKD 
with another such key to MAC CSMs. 

Description: The ARTMK instruction re-enciphers a 64 bit key K from encipherment under a 128 bit or replicated 
55 64 bit key encrypting key *KK (called the IMPORT KEY) to encipherment under the master key. A 1 28 bit key K can be 
imported by invoking ARTMK twice, once for each 64 bit half. 

ARTMK may be used to import notarised or non-notarised keys in accordance with ANSI X9. 1 7. ANSI non-notarised 
keys may be imported by invoking ARTMK with a key encrypting key shared with the key sender. ARTMK internally 
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performs offsetting on the specified key encrypting key using the specified counter value. ANSI notarised keys may be 
imported by invoking ARFMK with the partial notarising form of a key encrypting key shared with the key sender ARTMK 
performs offsetting on the specified partial notarising key using the specified counter value to internally form the notarising 
key. Partial notarising keys are formed from key encrypting keys by the APNOTR instruction. 

In ANSI X9.17, one or two KDs may be received in a single CSM. If one KD is received, it may be ultimately used 
as either a privacy key or MAC key. The CSM itself is authenticated with the received KD. If two KDs are received, the 
first KD is a MAC key and the second is a privacy key. The CSM is authenticated with the exclusive-OR of the two KDs. 

ARTMK supports CSM authentication by outputting imported data keys in two operational forms. The first form of 
the KD is its ultimate usage, i.e., privacy or MAC, as specified by parameter C2. The second form of the KD may be 
used to directly MAC the CSM (as in the case of a single KD above), or may be combined (exclusive-ORed) with another 
imported KD of this form to create a key to MAC the CSM. The latter usage corresponds to the case of two KDs in a 
single CSM. Parameter C3 controls whether the second output form is a MAC key or 'partial' MAC key. The ACOMBKD 
is used to combine partial MAC keys from two ARTMK invocations into a single CSM MAC key. 

Figure 54 shows the ARTMK functional block diagram. 

#CC: 

1 . successful operation 

2. C1 L or C1R is invalid 

3. C2 is invalid 

4. C3 is invalid 

5. unsuccessful operation (error). 
# Control Vector Checking: 

1. Checking on C1L: 

- CVtype = °KEK/ANSr 
-- ARTMK Usage bit = 'V 
-- reserved (48:63) = X'O' 

2. Checking on C1R: 

-- CVtype = "KEK/ANSI" 

- ARTMK Usage bit = T 

- reserved (48:63) = X'O' 

3. Checking on C2: 

- CV type = "KEK/ANSI" or "data/ANSI" 
-- ARTMK Usage bit = '1' 

If CV type = "data/ANSI" then do the following checking: 

— Figure 55 shows the valid combinations of C2 attributes which must be checked. Any combination 
other than those in the table is cryptographically invalid and thus must not be allowed. E, D, MG, MV, 
AC MB are the usage bits for the data key control vector. 

4. Checking on C2 & C1 L.C1 R: 

- Figure 56 shows the valid combinations of C2 type and Key Form versus C1 L and C1 R Key Form attributes. 
These attributes are checked to enforce left versus right half separation and to ensure that a true 128 bit 
KEK may only be imported under a 128 bit KEK. Any other combinations of these attributes other than 
those in this table are cryptographically invalid and thus must not be allowed. 

- 5. Checking on C3: 

-- CV type = "data/ANSI" 
-- reserved (48:63) = X'O' 
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— export control bit 1 = 1 (no export) 

— Figure* 57 shows the valid combinations of C3 attributes which must be checked. Any combination other 
than those in the table is cryptographically invalid and thus must not be allowed. E, D, MG, MV, ACMB are 

5 the usage bits for the data key control vector. 

ANSI transLaTe a KEY (AXLTKEY) 



10 

- Equation: e*KM.ClL(KK1L), e*KM.ClR(KK1R), e*KM.C2L(KK2L), e*KM.C2R(KK2R), e*KK1o((*)K), (e(*)Ko(KD- 
mac)), cntn, cntr2, key-type, C1L.C1R, C2L.C2R, C3 === e*KK2o(K), e*KM.C3(K) (key-type = 0, KD) 
or 

e*KK2o((*)K),e*KM.C3(KDmac) (key-type = 1, KEK) 
is - Inputs: e*KM.C1L(KK1 L) left 64 bits of *KK1 , denoted KK1 L, encrypted under the master key with a control vector 
C1L 

*KK1 is a 128 bit KEK or partial notarising KEK. 
20 e*KM.C1 R(KK1 R) right 64 bits of *KK1 , denoted KK1 R, encrypted under the master key with a control vector C1 R. 
*KK1 is a 128 bit KEK or partial notarising KEK. 

NOTE: *KK1 is offset with counter cntrl to internally form *KK1o, the input key encrypting key. If the key to be 
translated is input in notarised form, *KK1 must be partial notarising key, denoted *KKNI1, as created by the APNOTR 
25 instruction. *KK1o in this case is a notarising key. 

e*KM.C2L(KK2L) left 64 bits of *KK2, denoted KK2L, encrypted under the master key with a control vector C2L 

*KK2 is a 128 bit KEK or partial notarising KEK. 

30 

e*KM.C2R(KK2R) right 64 bits of *KK2, denoted KK2R, encrypted under the master key with a control vector C2R. 
*KK2 is a 128 bit KEK or partial notarising KEK. 

NOTE: *KK2 is offset with counter cntr2 to internally form *KK2o, the output key encrypting key. If the key to be 
35 translated is input in notarised form,*KK2 must be partial notarising key, denoted *KKNI2, as created by the APNOTR 
instruction. *KK2o in this case is a notarising key. 

e*KK1o((*)K) 64 bit or 128 bit ANSI key (KD or KEK), denoted (*)K, to be translated. 

40 (*)K is triple encrypted under (*KK1o, where *KK1o is *KK1 offset by 

cntrl . If (*)K is 128 bits, i.e., I* = K1//Kr, then this parameter is input as e*KK1o(K1 )//e*KK1o(Kr). Otherwise 

if (*)K is 64 bits, then this parameter is input as e*KK1o(K). 
e(*)Ko(KDmac) optional 64 bit MAC key, KDmac, encrypted under (K)Ko; i.e., single encrypted under 64 bit K offset 
4S by zero or triple encrypted under 128 bit *K offset by zero. 

In this case, (*)Ko = (*)K, so e(*)Ko(KDmac) = e(*)K(KDmac). KDmac is a temporary MAC key used in ANSI X9.17 
to authenticate Cryptographic Service Messages (CSM) at a Key Translation Centre (KTC). A KDmac always accom- 
panies a CSM request to translate a KEK at the KTC. No KDmac accompanies a CSM request to translate KDs since 
50 the data key(s) themselves are used as a MAC key to authenticate CSMs to/from the KTC. Thus, this parameter is vatid 
only if the key-type is 1 , i.e., (*)K is a KEK. 

cntrl 64 bit clear counter value associated with the key encrypting key *KK1 . 

55 This value is ordinarily supplied by the key sender and represents the counter used to offset *KK1 before encrypting 

(*)K. Cntrl should be compared with the corresponding local receive-counter for *KK in accordance with ANSI X9.17 
Counter Management before invoking AXLTKEY to translate the received key. The comparison and AXLTKE Y-invocation 
step should be performed atomically within CFAP to preserve integrity. KEK counters are maintained by the CFAP with 
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integrity. 

cntr2 64 bit clear send-counter value associated with key encrypting key *KK2. 

This value is ordinarily transmitted along with the translated key to the intended recipient. The recipient uses the 
received counter to detect replay, to synchronise its local receive-counter for *KK2, and to recover the translated key. 
Local counters are maintained by the CFAP with integrity. 

key-type specifies the type of the key to be translated. 

- 0: KD 

- 1: (*)KK, i.e., 64 bit or 128 bit KEK 

C1 L.C1 R 64 bit control vectors for the left and right parts of the input key encrypting key or partial notarising key, 
respectively. 

C2L,C2R 64 bit control vectors for the left and right parts of the output key encrypting key or partial notarising key, 
respectively. 

C3 64 bit control vector for the CSM MAC key to partial MAC key to be stored under KM. 

If one KEK or exactly one KD is to be translated, C3 should specify MACGEN and MACVER attributes. If two KDs 
are to be translated, C3 should specify ACOMBKD attribute to create a 'partial' MAC key. Two calls to AXLTKEY are 
required to translate two KDs. The two resulting partial MAC keys can be combined using ACOMBKD instruction to form 
a CSM MAC key with MACGEN and MACVER attributes. 

Outputs: e*KK2o((*)K) 64 bit or 128 bit key, (*)K, triple encrypted under *KK2o is the output key encrypting key 

*KK2 offset by counter cntr2. 

If key-type is 0, (*)K is a 64 bit data key (i.e., (*)K = K) and this parameter is denoted e*KK2o(*). (*)K is translated 
from*KK1oto*KK2o. 

e*KM.C3(K) 64 bit MAC key or partial MAC key equal to translated data key K, triple encrypted under the master key 
with a control vector C3. 

This output is valid only if a KD is translated, i.e., key-type is 0. In ANSI X9.17, a KD to be translated is also used 
to authenticate the Cryptographic Service Messages to/from the KTC. If only one KD is to be translated, then the MAC 
key is the KD itself. In this case, e*KM.C3(K) is just the KD, K, in a form directly usable by GENMAC and VERMAC to 
MAC the CSMs. If the two KDs are to be translated, the MAC key is formed by exclusive-ORing the two KDs. In this 
case, AXLTKEY must be called twice, i.e., once to translate each KD. Then e*KM.C3(K) from each call is a partial MAC 
key. The two partial MAC keys may be combined with ACOMBKD instruction to form a key directly usable by GENMAC 
and VERMAC to MAC the CSMs. 

e*KM.C3(KDmac) 64 bit MAC key KDmac, triple encrypted under the master key with a control vector C3. 

This output is valid only if a KEK is translated, i.e., key-type is 1. In ANSI X9.17, KDmac is used to authenticate 
CSMs to/from the KTC. 

Description: AXLTKEY instruction translates a 64 bit or 128 bit key, denoted (*)K, from encryption under offset key 
encrypting key *KK1 to encryption under offset key encrypting key *KK2. Besides offsetting, AXLTKEY supports trans- 
lation from/to notarised key forms. If (*)K is input in notarised form, *KK1 must be a partial notarising key. Likewise, if 
(*)K is to be output in notarised form, *KK2 must be a partial notarising key. Partial notarising keys are formed from 
KEKs by the APNOTR instruction. 

AXLTKEY also produces a secondary output: a MAC key or MAC key component, which may be used to authenticate 
Cryptographic Service Messages between the translation requester and the KTC. The MAC key formation is controlled 
by the key-type parameter. 

If key-type is 1, i.e. KEK translation, then the MAC key is supplied to the instruction as an optional parameter, 
KDmac, encrypted under the KEK itself (offset by 0). AXLTKEY recovers KDmac internally and outputs it re-enciphered 
under KM with control vector specified by parameter C3. Typically C3 is specified with GENMAC and VERMAC usage 
attributes; hardware enforces no-export control. 

If key-type is 0, i.e., KD translation, then the MAC key is based on the KDs to bed translated. AXLTKEY recovers 
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the KD internally and outputs it re-enciphered under KM with attributes controlled by C3. If exactly one KD is to be 
translated, the MAC key is KD itself and C3 is typically specified with GENMAC and VERMAC usage. Again, the hardware 
enforces export control. If two KDs, KD1 and KD2 are to be translated, AXLTKEY must be invoked twice, the MAC key 
is KD1 XOR KD2, and C3 must be specified with ACOMBKD attributes. The resultant MAC key components, e*KM.C3 
5 (KD1 ) and e*(KM.C3(KD2), may then be passed to the ACOMBKD instruction, which recovers them internally and pro- 
duces e*KM.CxKD1 XOR KD2), the required MAC key. 

Figs. 58 and 59 show the AXLTKEY functional block diagram. 

AXLTKEY instruction is used in the ANSI X9.17 KTC environment. The instruction supports the processing of the 
Request for Service (RFS) CSM and the generation of the corresponding Response to Request (RTR) CSM. The RFS 
10 may contain one of the following translation requests: 

Translate one data key "D1 ; use KD1 to MAC these CMSs. 
- Translate two data keys KD1 , KD2; use (KD1 XOR KD2) to MAC CSMs. 
Translate one KK or *KK; use supplied data key KDmac to MAC CSMs. 

75 

When one data key KD1 has to be translated, the AXLTKEY function translates the key and also outputs e*KM.C3 
(KD1 ), which can be used for verifying the MAC in the RFS and generating a MAC for the corresponding RTR. 

When two data keys, KD1 and KD2 have to be translated, AXLTKEY function is invoked twice. It generates e*KM.C3 
(KD1) and e*KM.C3(KD2) as intermediate outputs in two respective calls. CFAP then calls ACOMBKD to combine the 
20 two outputs into one MAC key e*KM.CX(KD1 XOR KD2), which can be used to MAC the RFS and RTR CSMs. The 
intermediate outputs generated by AXLTKEY can only be used locally with no export authority; this is enforced by the 
control vector checking. 

When one (*)KK key has to be translated, the AXLTKEY function translates the key and also outputs e*KM.C3 
(KDmac) which can be used for MACint the CSMs. KDmac accompanies the (*)KK to be translated in the RFS; it is 
25 encrypted under the (*)KK offset with constant zero. Note that e*KM.C3(KDmac) can only be used locally; the export 
control is enforced by control vector checking in the instruction. 

#CC: 

30 - 1. successful operation 

2. C1LorC1Ris invalid 

3. C2L or C2R is invalid 

4. C3 is invalid 

5. unsuccessful operation (error). 

35 

# Control Vector Checking 

1. Checking on C1L: 

40 ~ CV type = "KEK/ANSI" 

~ AXLTKEY Usage bit = 1 
reserved (48:63) = X'O" 

2. Checking on C1R: 

45 

- CV type = "KEK/ANSI" 

- AXLTKEY Usage bit = 1 
reserved (48:63) = X'O* 

50 - 3. Checking on C2L: 

- CV type = "KEK/ANSI" 

- AXLTKEY Usage bit = 1 
-- reserved (48:63) = X'O' 

55 

4. Checking on C24: 

- CV type = "KEK/ANSI° 
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-- AXLTKEY Usage bit = 1 
-- reserved (48:63) = X'C 

5. Checking on C1 L and C2L: 

5 

- key form (C1L) = key form(C2L) 

6. Checking on C1 R and C2R: 

io « key form (C1R) = key form(C2L) 

7. Checking on C3: 

~ key type = "kata key 8 
is — export control bits 1 = 1 (no export) 

— Fig. 60 shows the valid combinations of C3 attributes which must be checked. Any combination other than 
those in the table is cryptograph ically invalid and thus must not be allowed. E, D, MG, MV, AC MB are the 
usage bits for the data key control vector. 

20 

ANSI COMBine KDS (ACOMBKD) 



2S - Equation: e*KM. C1 (KD1 ), e*KM. C2(KD2), C1 , C2, C3 ==== e*KM.C3(KD) 

Inputs: e*KM.C1 (KD1 ) 64 bit ANSI data key triple encrypted under the master key KM with a control vector C1 . 
e*KM.C2(KD2) 64 bit ANSI data key triple encrypted under the master key KM with a control vector C2. 

C1 64 bit control vector for the data key KD1 . 
30 C2 64 bit control vector for the data key KD2. 

C3 64 bit control vector for the output MAC key, KD. 

Outputs: e*KM.C3(KD) 64 bit ANSI data key triple encrypted under the master key with control vector C3. 

35 This key can be used to authenticate ANSI X9.17 Cryptographic Service Message using the GMAC and VMAC 

instructions. 

Description: In ANSI X9.1 7, keys are exchanged by communicating parities via a sequence of Cryptographic Service 
Messages (CSMs). Every exchange includes one or two data keys. The integrity of certain CSMs is protected by MACing 
the CSM with the data itself, if one KD is being exchanged, or with the exclusive-OR of the two data keys, if two KDs 
40 are being exchanged. ACOMBKD instruction addresses the latter case, i.e., the computation of a CSM MAC key from 
two data keys. 

ACOMBKD accepts two 'partial' MAC keys, i.e., data keys encrypted under the master key with a control vector 
which permits their use in ACOMBKD. Partial MAC keys are created as an optional by-product of importing or exporting 
ANSI data keys with ARTMK or ARFMK, respectively. 
45 ACOMBKD recovers the data keys KD1 and KD2 internally and outputs (KD1 XOR KD2), enciphered under the 

master key with a control vector which permits its operational use with GMAC and VMAC instructions. These instructions 
may be used to authenticate incoming and outgoing CSMs as required by the ANSI X9.17 CSM protocol. 

NOTE: ACOMBKD must verify that the input KDs are not equal, or equivalent, that (KD1 XOR KD2) is not equal to 
sero. This is to prevent creation of a MAC key with a known value (sero). 
50 Fig. 61 shows the block diagram of the ACOMBKD instruction. 

#CC: 



55 

1 . successful operation 

2. C1 is invalid 

3. C2 is invalid 
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4. C3 is invalid 

5. unsuccessful operation (error) 
Control Vector Checking 

5 



1. Checking on C1: 

10 - CV type = "data/ ANSI 0 

— ACMB Usage bit = 1 

— reserved (48:63) = X'O* 

— Fig. 62 shows the valid combination of C1 attributes which must be checked. Any combination other than the 
'5 one in the table is cryptographically invalid and thus must not be allowed. E, D, G, MV, ACMB are the usage 

bits for the data key control vector. 

2. Checking on C2 

20 - key type = "data/ANSI 

ACMB Usage bit = 1 

— reserved (40:63) = X'O' 

— Fig. 63 shows the valid combination of C2 attributes which must be checked. Any combination other than the 
25 one in the table is cryptographically invalid and thus must not be allowed. E, D, MG, MV, ACMB are the usage 

bits for the data key control vector. 

3. Checking on C3: 

30 - CV type = •data/ANSI 0 

— export control bit 1 = 1 (no export permitted) 
reserved (48:63) = X'O' 

— Fig. 64 shows the valid combination of C3 attributes which must be checked. Any combination other than the 
35 one in the table is cryptographically invalid and thus must not be allowed. E, D, MG, MV, ACMB are the usage 

bits for the data key control vector. 

ICV/OCV Management 

40 An initial value (ICV) is a 64 bit random, pseudo-random, or, in some cases, non-repeating value used with the 

cipher block chaining (CBC) mode of encryption of the DEAand with some algorithms for calculating message authen- 
tication codes (MACs). 

ICV management includes options for electronic transmission and local storage of both plain and encrypted ICVs. 
However, encrypted ICVs must first be decrypted before being used as input parameters to any of the cryptographic 
45 functions. 

An output chaining value (OCV) is a 64 bit value returned, under certain conditions, by the GENMAC and VERMAC 
cryptographic instructions. The same cryptographic instruction is again called and the OCV is passed as the ICV. The 
OCV is always encrypted in the form eKM.CV(OCV), where CV is a control vector for intermediate ICV. For the VERMAC 
instruction, an encrypted OCV is absolutely essential for reasons of security. A plain OCV, in this case, could be used 
50 to reveal MACs, which is something that the VERMAC instruction is not supposed to do. An encrypted OCV is also 
defined for the GENMAC instruction. This is done so that the GENMAC and VERMAC instructions are made as similar 
as possible, thus allowing for possible function overlap in hardware. 

ICV Management Outside the Cryptographic Facility 

55 ~ 

The Communication Architecture permits the following three modes of electronic transmission of the ICV: 
1. Plain ICV: sent in the clear. 
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2. Encrypted ICV: encrypted with a data key (KD) shared between the sender and receiver. 

3. Private Protocol: ICV established using a private protocol between sender and receiver 

Under the CA, CFAP must handle both plain and encrypted ICVs. Although, applications may elect to manage their 
5 own encrypted ICVs thus passing plain ICVs to CFAP to encrypt ICVs for transmission and to decrypt all encrypted IDVs 
received from other nodes. Optionally, the crytographic support program may also establish ICVs using a private protocol. 

ICV Management Inside the Cryptographic Facility 

10 Control vectors are not used for the electronic distribution of IDVs, nor are there any bits in the control vector that 

may be used by the cryptographic facility (hardware) to control ICV distribution. There is no checking or enforcement 
by the cryptographic facility of the mode of ICV distribution. Thus, ICV management is strictly a function of the crypto- 
graphic support program (i.e., software external to the cryptographic facility). 

All ICVs passed as cryptographic function input parameters to the cryptographic facility must be plain ICVs. ICV = 

15 o, which is required by the GENMAC and VERM AC instructions, is just a subcase of Plain IC V Tne affected cryptographic 
instructions are these: 

1. Encipher 

2. Decipher 
20 - 3. Genmac 

4. Vermac 

5. Translate Cipher Text 
Key Management 

25 

The Crypto Architecture Key Management is a set of techniques, rules and procedures for managing keys through 
the effective utilisation of the instruction set and other facilities (e.g., key loading facility, registers, etc.) of the Crypto- 
graphic Facility. 

It is the intent of the cryptographic architecture that key management is performed using the specified cryptographic 
30 functions in the stated ways. This ensures that systems implementing the common cryptographic architecture can com- 
municate with each other using one common method. Some of the features of the CA Key management are listed below. 

The Key management is based on the control vector concept, which offers, among several advantages, powerful 
enforcement of the usage of keys to insure keys are separated and used as intended. 

35 

Internal to a system, the Key management is a two-level-of-hierarchy concept, enforced by the cryptographic facility: 
Only the master key is stored in the clear inside the secured crytographic facility. Other keys are encrypted under 
an exclusive OR of the master key with a control vector associated to each key, and can be stored outside the crypto 
facility. No clear key is allowed outside the crypto facility. 

40 

The key management is also a three-level hierarchy in communication aspects, enforced by the CFAP (Crytographic 
Facility Access Program): the master key is used to encrypt key-encrypting keys, key encrypting keys that are shared 
between modes are used to encrypt other keys exchanged among them. 

45 - it provides procedures of initialising keys on system and networks. 

It provides procedures for the generation, distribution, exchange and storage of keys. 

It provides communication protocols for the transmission of keys and control vectors between nodes. 

50 

CA Key Management Design Philosophy 
Control Vector System 
55 a control vector system is a cryptographic system implementing the CA. 
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Storage of Keys and Cryptographic Variables 

All keys are stored in the form eKM.C(K), i.e., encrypted under a key formed by Exclusive-ORing the master key 
with a control vector. Intermediate MAC ICVs and Tokens are also encrypted similarly. 

Key and Cryptographic Variable Types 

The CV Type/Subtype field in the control vector designates the key or cryptographic variable encrypted. Thirteen 
CV types/subtypes are defined to CA: 

CV Type/Subtype 

Data/Privacy 
Data/MAC 

- Data/Xlate 

- Data/Comp 

- Data/ANSI 
-- KeK/Sender 
-- Kek/Receiver 

Kek/ANSI 
~ PIN/Encrypting 
PI N/G en e rating 

- ICV/tntermediate MAC 

- Key Part/ 

- Token/ 

The CV type/subtypes can be divided into three categories: 

- 1 . CA: defines keys shared only with other CA systems. 

• 2. Compatibility: defines keys shared with other CA and non-CA systems. 

3. ANSI: defines keys sent/received via ANSI X9.17 key distribution. 



Category CV Type/Subtype 

CA Data/Privacy 

Data/MAC 
Data/Xlate 
KeK/Sender 



75 



EP 0 356 065 B1 



Kek/Receiver 
Kek/ANSI 

5 

PIN/Encrypting 
PIN/Generating 
ICV/Intermediate MAC 
10 Key Part/ 

Token/ 

15 Compatibility Data/Comp 

ANSI Data/ANSI 

Kek/ANSI 

20 



Key Hierarchy 

25 



1 . Master Key: encrypts all keys stored locally external to the cryptographic facility. 

2. Key Encrypting Key: encrypts all keys (except master key) communicated from one cryptographic facility to an- 
30 other. 

3. Data Key: encrypts data and ICV. 

4. PIN Encrypting Key: encrypts PIN Blocks. 

Key Distribution Protocols: 

35 

The CA supports three key distribution protocols: 

1 . Control Vector Mode (designated CV). All keys communicated on the link are of the form eKEK.C(K). 

2. Compatibility Mode (designated CV = 0). All keys communicated on the link are of the form eKEK(K). 

40 - 3. ANSI X9.17 Mode (designated ANSI). All keys communicated on the link conform to ANSI Standard X9.17. 

Key Distribution Rules 

Keys and crypto- variables are distributed (exported/imported) according to a set of rules which relates key categories 
45 to key distribution protocols, as follows: 

1 . CA keys and crypto-variables must be exported/imported using the Control Vector Mode. 

2. Compatibility Keys can be exported/imported using either the Control Vector Mode (using the control vector on 
the link) or the Compatibility Mode (using CV = 0 on the link). 

so - 3. ANSI keys must be exported/imported using the ANSI X9.17 Mode. 

These rules are summarised in the table below: 



55 
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Category 



CV Type/Subtype 



Key Distribution Protocol 



CV 



CV » 0 



ANSI 



CA 



Data/Privacy 

Data/MAC y 

Data/Xlate - y 

KeK/Sender y 

Kek/Receiver y 

Kek/ANSI y 

PIN/Encrypting y 

PIN/Generating y 

ICV/lntennediate y 
# MAC 

Key Part/ y 

Token/ y 



Compatibility Data/Comp y y 

ANSI Data/ ANSI y 

Kek/ANSI y 



Legend; M y" denotes variable can be distributed via the indicated key 
distribution protocol. 

Key States (non-ANSI) 

The CA defines three key states: 

1. Operational: key is encrypted under KM, i.e., in a form suitable for local use. 

2. Export: key is encrypted under a KEK Sender, i.e., in a form suitable for export to another device. 

3. Import: key is encrypted under a KEK Receiver, i.e., in a form suitable for import at this device. 

Key Generation 



1 . Every key generated by a control vector system has a control vector associated with it. 
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2. Keys may be generated in the a) operational state, b) export state, c) import state depending on the C V type/sub- 
type of the key used to encrypt the generated key (item G in this list). 

3. Keys are generated via the GKS and KGEN instructions. 

5 GKS generates a key in two forms using the two control vectors. The CV type/subtypes must both be of the CA 

category. (Key management does not permit a key to be both a CA and a compatibility category key. 
KGEN generates a key in one form using a control vector either of the CA or Compatibility Category. 

Key State Transitions (non-ANSI) 

10 

The following key state transitions (via the indicated instructions) are supported by CA: 



Input State Output State 

Operational Import Export 



20 

Operational - - RFMK 

Import RTMK - XLATE KEY 

Export - - 

25 



Legend: denotes not supported 

30 

Instruction Sequences to Perform Key Management 

The tables in Figs. 65, 66, 67 and 68 specify the CA functions to be used for key management purposes. Detailed 
35 descriptions can be found in the sections that follow. 

Key States and Instructions 

Fig. 69 shows the relationship of Operations, Exported and Imported keys and how these keys may be created or 
40 transformed by various instructions in the crypto facility. 

An Operational key is kept in key storage and is usable as an input parameter to crypto instructions. It is in the form 
eKM.C(K) where KM is the Master Key kept in the crypto facility and C is the CV associated with key K. An Export key 
is an Operational key that defines a channel to be used for sending keys to another system. An Import key is an Oper- 
ational key that defines a channel to be used for receiving keys from another system or from yourself. An Exported key 
45 is a key of the form eKEK.C(K) where KEK is a KEK Sender and C is the CV associated with key K. An Imported Key 
is a key of the form eKEK.C(K) where KEK is a KEK Receiver and C is the CV associated with key K. 

RFMK transforms an Operational key into an Exported key. RTMK transforms an Imported key into an Operational 
key. KGEN generates one form of an Operational key. XLATEKEY translates an Imported key to an Exported key. GKS, 
in general, generates a key in two forms. One form may have different usage attributes from the other form. GKS OP-OP 
so generates a key in two forms, Operational and Exported. GKS OP-IM generates a key in two forms. Operational and 
Imported. GKS IM-EX generates a key in two forms, Imported and Exported. GKS EX-EX generates a key in two forms, 
Exported and Exported. 

An Overview of Key Types 

55 

The CA instruction operates on the following key types: 
1 . Ken-encrypting keys 
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These are the keys that are used to encrypt other keys. The Master key, Cross Domain keys and Terminal 
master keys are key-encrypting keys. Except for the master key, all key-encrypting keys can be classified into the 
following subtypes: 

5 mm Key-encrypting key sender (KEK sender): a key used to send keys to other nodes. 

~ Key-encrypting key receiver (KEK receiver): a key used to receive keys sent from other nodes. 

- ANSI Key-encrypting key (ANSI KEK): a key used in the ANSI X9. 17 key management environment. The ANSI 
10 KEK does not have the uni-directional characteristics of regular CA KEK (i.e., KEK Sender and KEK Receiver) 

— Master Key - The Master key is the key used to protect all other keys in the system. 

Only the master key needs to be stored in the clear inside the secured cryptographic facility. Other keys are protected 
is under the encryption of the master key XORed with a control vector associated with each key. Since they are encrypted, 
they can be stored in storage areas outside the cryptographic facility. 

The CA requires that the master key is a double length key, i.e. , it must be 1 28 bits long, of which 1 1 2 bits represent 
the actual value and 16 bits are the parity bits. 

20 mm Cross-domain key - Key management calls for a unique double length key parity (128 bits each) to be shared with 
each CV-type (control vector type) node for which it desires to communicate. 

This is also true for non-CV-type system nodes, where for systems employing only single length keys a double 
length key pair is stored such that the left and right halves are equal. The cross-domain keys are used to encrypt (or 
25 ship) and retrieve keys exchanged between nodes that share the cross-domain keys. 

- Terminal Master Keys - Key management calls for a unique terminal master key to be shred with each terminal with 
which it desires to communicate. 

30 For terminats where it is necessary only to send keys to the terminal, but not receive keys, the terminal will ordinarily 

store only a single length terminal master key (64 bits). In these cases, the double length key is stored in the key storage, 
where the left and right halves are equal. 

In cases where the terminal stores a double length key, this key will be stored unchanged in the key storage. 

35-2. Data keys - Data keys are used to encrypt data. Authentication keys, file keys and session keys are included in 
this category. 

3. PIN keys - PIN keys are classified into two sub-types: 

40 - PIN-encrypting keys: these are keys used ot encrypt PINs. 

« PIN-generating keys: these are keys used in PIN generation algorithms to generate PINs. 

4. Key part - A key part is a part or a component of a key, having the same length as the key. For example, a key 
K may have two key parts Ka and Kb such that Ka XOR Kb = K. 

45 

5. Intermediate ICV - An Intermediate ICV is used to encrypt the intermediate Output Chaining vector of a segment 
of data or message. 

This OCV is then fed into the next segment of the data and used as an ICV. This occurs when a message or data 
so on which a MAC to be generated/verified is long and must be divided into shorter segments. 

6. Token - Tokens are variables used to protect the integrity of the data keys stored in the Data Key Dataset (a key 
storage for Data keys). 

55 They help prevent the access of data keys by unauthorised users. 
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Key Initialisation 

The following is a discussion on mechanisms for key initialisation. 

When the system is first set up, the master key should be the first key to be installed. Then some key-encrypting 
s keys such as Cross domain keys or transport keys can be manually installed. Once Cross domain keys are available, 
the system can exchange keys and encrypted data with other systems. 

The master key and other key encrypting keys shall be manually installed under proper access controls. 

The key entry device through which the key is entered to the Cryptographic Facility must have a secure interface 
to the Cryptographic Facility, as does the panel display (if not part of the key entry device). This is discussed in "Physical 
10 Facilities and Interface." 

When a master key or any other key-encrypting key is to be manually installed, dual key entry, which aims to prevent 
complete knowledge of key(s) by any single individual, is highly desirable. In a dual key-entry procedure, the key is 
entered in two parts. Each key part is of equal length to the key and is entered by a separate person. The actual key is 
the Exclusive OR of the two key parts. 
is The CA supports multiple-key entry (i.e., when a key K has more than two key parts; for example, the key may have 

n key parts KP1, KP2,... KPn such that K = KP1 XOR KP2 ... XOR Kpn). 

When dual key entry is required for a system, the key loading facility and other facilities of the crypto facility should 
be designed to readily support this. For example, there should be two physical key locks (or one key lock with two 
separate keys for two positions) to enable the entry of each key part separately. In systems where there is no physical 
20 key, schemes can employee passwords to be entered, one password for each key part. When a key or any part of a 
key is entered, it should be visually verified only by the person who enters it. Once that person sees that the display 
agrees with what he typed, he can activate the loading of the key or key part into registers inside the cryptographic 
facility (e.g., by means of a button that interfaces the key entry device with the key registers). Every key or key part to 
be entered must be of double length, including the 16 bit odd-parity. Parity is included for the purpose of error checking. 

25 

Manual entry of Master Key 

The CA does not define a specific method for the manual installation of the master key. The method outlined in this 
section is provided as a guideline. It is recommended that the entered master key bed temporarily stored in a new master 
30 key register and is not made active until a Set Master Key function is issued. 

This strategy permits the entered master key to be verified and re-entered, if necessary, and the entered master 
key need not be activated until after a decision has been made that the entered key is correct and all processing re- 
quirements such as re-encipherment of other keys from the current master key to the new master key have been done. 
As part of the manual entry of the master key, a 32 to 64 bit non-secret verification pattern (function of the entered 
35 master key) should be returned at the physical interface or programming interface or both. Alternatively, the verification 
pattern can be produced in response to a key installed utility invoking an instruction. The verification pattern is useful in 
environments where it is not secure to display an entered key on a panel or console for the user to verify. Specific 
verification techniques are not within the scope of this document. 

Manual key entry (of the Master Key or Key Encrypting Keys) may be implemented with a Keypad attached to the 
40 CF via a physically secure interface. A physical key switch and/or passwords may be used to enable and disable the 
loading of keys from the Keypad. 

Master Key Activation 

45 An entered master key is made active by issuing a Set Master Key function. This causes the contents of the new 

master key register to be transferred to the master key register (i.e., current master key register). 

Optionally, the CA provides for an old master key register. In that case, a set master key function first causes the 

contents of the master key register to be stored in the old master key register and then the contents of the new master 

key register to be stored in the master key register. 
so Each master key register (new, current and optionally old) has an associated flag which is set ( = 1 ) whenever a 

key has been actively stored in the register and is reset ( = 0) whenever a key is deactivated or the cryptographic facility 

is powered on following a power off state. 

Installation of Keys Via Program Interface 

55 ~ * ~" 

A key can also be installed via a program interface. However, this method requires manual intervention by security 
officers (or issuers) with the possession of the physical key or access passwords. In this method, the user changes the 
operating state of the cryptographic facility into a state called super-secure mode by means of the physical key (or 
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passwords), then feeds a clear key and the associated control vector into the EMK instruction, which operates only in 
this mode. The EMK function enciphers the clear key under the master key XORed with the control vector. The encrypted 
key and the control vector are stored for use on the system. 

5 Suggested Rules for Setting, Testing and Enforcing Odd Key Parity 

Every short key consists of 64 bits, numbered by convention from 0 to 63, where bit 0 is the most significant bits. 
The parity bits are bits 7, 15, 23, 31 , 39, 47, 55 and 63, where bit 7 is the parity bit of key bits 0 through 6, bit 15 is the 
parity bit of key bits 8 through 14, etc. 

10 

Setting Odd Key Parity . 

All non-data keys imported into the system should have odd parity adjusted on the key. This includes the master 
key and all key encrypting keys, PIN encrypting keys and PIN generating keys encrypted and stored in the Key Storage. 
'5 All generated keys are odd parity adjusted, except if the key is generated as a random number and defined as the 

desired key already encrypted under another key. 

Testing Key Parity 

20 Before the cryptographic facility uses a key, it should check the key for odd key parity. Condition codes should be 

set to indicate whether the key has odd parity or not. The CFAP should make a determination whether the lack of odd 
key parity is an error, and whether the output of a requested function using the key can be trusted or not. 

Hardware Enforcement of Odd Key Parity 

25 

The hardware should enforce odd parity on the master key. If a parity error is detected, the requested crypt instruciton 
should be aborted. The hardware should attempt to recover (e.g., by using a backup copy of the master key), and should 
set a condition code to indicate that an unrecoverable master key parity error has occurred. 

In certain selected cases, a parity error for a key encrypting key or other non-data key may cause a requested 
30 cryptographic function to be aborted. 

Generation of Keys 

Keys should be generated in a random manner. This implies a hardware random number generator or a software 
35 implementation of an acceptable algorithm is required for electronic generation of keys. Keys can also be manually 
generated in a random manner, such as by coin tossings. Keys that are generated can be parity adjusted or non-parity. 
If parity is desired, keys must have odd parity. 

Manual Generation of Keys 

40 

The CA recommends that master keys and key encrypting keys be installed and generated manually. A good method 
for manual generation of keys is the coin tossing or dice throwing. One way to do the dice throwing is as follows: 

The involved courier or security officer selects eight 1 6-sided unbiased dies and assigns each side of a dice a value 
from 0 to 15 in hexadecimal. For example, side 1 have a value of 0, side 16 has a value of F, etc. The following steps 
45 are performed next: 

1 . Toss the dice (on a solid and level surface) and record the results in 8 HEX digits. 

2. Rewrite the results from HEX values into eight bytes of 8 binary bits each. 

50 

3. Compute the odd parity of the first seven bits of each byte. A total of 8 parity bits are formed for 8 bytes. 

4. Replace the eighth bit (last bit) of each byte to each corresponding parity bit computed in the preceding step. 
Rewrite the binary values into 8 hex digits. The result is the manually generated key in hex. 

55 

Electronic Generation of Keys 

Keys can be generated by the KEYGEN and GENKEY SET instructions defined in the instruction set section. 
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- By KEYGEN 

The KEYGEN instruction generates keys for immediate use on the system. 
5 - The KEYGEN permits the generation of clear keys. This mode would be used where couriers are involved. 

- The KEYGEN permits the generation of keys encrypted under the master key XORed with a specific control vector. 
This control vector is supplied to the instruction by the CFAP and is checked by the instruction for valid combinations. 

10 -ByGENKEYSET 

The GENKEY SET instruction generates keys and outputs them encrypted forms. This instruction always produces 
a pair (i.e., two copies of a key, in the following modes: 

is - Mode 0: OP-OP (operational-operational) mode 

This mode generates only data keys for local use on the system. Two copies of a data key are generated. Each 
copy of the key has an associated control vector with different attributes. For example, one copy of the key may have 
the MG (GENMAC) attribute while the other copy may have the MV (VMAC) attribute. Each copy is encrypted under 
20 the master key XORed with the corresponding control vector. 

- Mode 1 : OP-EX (operational-export) mode 

This mode generates one copy of the key to be used (and stored) locally and one copy of the key in a form ready 
25 to be exported to another control vector mode. The first copy, referred here as the local (or operational) copy, is encrypted 
under the master key (XORed with the associated control vector) and can later be exported to other nodes (by RFMK), 
depending whether it is allowed as specified in the export control field. (It is assumed that at the generation time, the 
owner of the key would know whether to allow the generated key to be exported. The other copy, referred here as the 
export copy, is encrypted under a KEK sender of the generating node (XORed with the copy's control vector). 

30 

-- Mode 2: EX-EX (export-export) mode 

A key generated in this mode cannot be used locally on the system. This mode generates two copies of a key in 
the forms ready to be exported to two control vector nodes. Each copy of the generated key, called the export copy, is 
35 encrypted under a different KEK sender (XORed with a corresponding control vector). The control vector associated to 
one copy of the key has different usage attributes from the control vector of the other copy. 

This mode is useful for distributing keys by nodes act as key distribution centres. 

- Mode 3: OP-IM (operational-import) mode 

40 

This mode generates one copy of the key to be used locally and one copy of the key in a form ready to be imported 
to the generating node. The first copy (called the operational or local copy) is encrypted under the master key (XORed 
with the associated control vector) and can later be exported to other nodes (by RFMK), depending on whether it is 
allowed as specified in the export control field. The other copy (called the import copy), is encrypted under a KEK receiver 

45 (XORed with the copy's control vector). 

This mode is useful for file applications. For example, in archiving sensitive data, the encrypted data and the data 
key (encrypted) are stored on the tape. But under what key the data key must be encrypted and stored on the tape? It's 
not desirable to store the data key encrypted under the master key because the master key might be changed later. It 
is more practical to encrypt the data key under a KEK sender (which is a file master key in this case) since KEKs have 

50 longer lifetime. In one application, the GENKEY SET instruction, mode OP-IM, generates a pair of data keys. The op- 
erational copy has the CV type = data/privacy and the Encipher usage attribute. The import copy has the CV type = 
data/xlate and the XDin = 1 attribute. The data is then encrypted by the local copy (via the ENCIPHER instruction). The 
encrypted data and the import copy are then archived. Later on, when it is desired to retrieve the data and re-encrypt 
the data under a new key, etc., the import copy is pulled off from the tape and recovered (via the RTMK instruction). 

55 Since the import copy has the XDin = 1 attribute, it can be used in the TRANSLATE CI PHER-TEXT instruction to translate 
the data to the encryption under a new key. Other applications that have been identified are the ones that require the 
operational copy and the import copy have usage attributes as specified in Fig. 37. 
NOTE: This mode can only produce data keys. 



82 



EP 0 356 065 B1 



~ Mode 4: IM-EX (import-export) mode 

This mode generates one copy of the key to be later imported by the generating node, and one copy of the key in 
a form ready to be exported to another node. The first copy (called the import copy) is encrypted under a KEK receiver 
5 (XORed with the associated control vector). It can later be retrieved by the generating node using the RTMK instruction. 
The other copy (called the export copy) is encrypted under a KEK sender (XORed with the copy's control vector). 

This mode is useful for IBM SNA multi-domain applications, where, for example, session keys are generated and 
distributed. 

NOTE: For every copy of the generated key, the CFAP must supply the associated control vector to the GEN KEY 
10 SET instruction. The GENKEY-SET instruction checks the control vectors of the copies of the generated key for valid 
usage and valid combinations of other attributes, depending on the mode of the instruction. 

Key Distribution 

'5 Keys can be distributed manually (e.g., by couriers) or electronically. Distribution by couriers is not desirable in 

networks with a large number of nodes since the distribution cost could be excessive. In many cases, electronic distri- 
bution of keys is the preferred method. 

Key Distribution Protocols 

20 

Cryptographic nodes in a network usually is a mixture of nodes that have the control vector capability and some 
other nodes that do not have the control vector capability. The first type of nodes is referred to here as control vector 
nodes, and the second type is referred to as non-control vector nodes. Examples of non- control vector nodes are some 
existing IBM crypto products such as 4700, 3848/CUSR Protocols for key distribution between nodes of the same type 
25 of different type are: 

Control Vector Mode (designated CV) 
Compatibility Mode (designated CV = 0) 
- ANSI X9. 1 7 Mode (designated ANSI ) 

30 

The Control Vector Mode is a method whereby all keys communicated from one cryptographic facility to another 
(on the link) are cryptograph really separated according to key type and designated key usage. Every key communicated 
on the link is of the form eKEK.C(K), where K is the key being communicated, KEK is the key encrypting key under 
which the key K is encrypted and C is the control vector associated with key K. The control vector C may or may not 
36 accompany the encrypted key eKEK.C(K) during transmittal. This mode is CV, since control vectors are maintained on 
the link. 

The Compatibility Mode is a method whereby all keys communicated from one cryptographic facility to another (on 
the link) are of the form eKEK(K). No cryptographic separation is provided in the compatibility mode. The compatibility 
mode is provided so that keys can be distributed to existing IBM cryptographic systems (PCF, CUSP/3848, 4700) which 

40 use this method of key distribution. Currently, SNA crypto support is limited to key distribution using this mode. Distribution 
of keys in this mode is limited to data keys (with encipher and decipher usage attributes) and MAC key (with MACGEN 
and MACVER usage attributes). This mode is designated CV = 0, since it is equivalent to using a control vector of all 
seros on the link. Key distribution is accomplished using the CV = 0 option provided link. Key distribution is accomplished 
using the CV = 0 option provided under the CA cryptographic instructions and the CA CFAP macros. 

45 The ANSI X9. 1 7 Mode is a method of key distribution which complies with ANSI-specific C A-provided cryptographic 

instructions and a subset of ANSI -specific DDA-provided CFAP macros. 

Each mode of key distribution has a set of associated rules and procedures which collectively define that key dis- 
tribution method. Each key encrypting key shared between cryptographic facilities for the purpose of key transmittal 
between the respective cryptographic facilities defines a cryptographic communication CHANNEL, or key distribution 

so channel. Such a channel may be a CV channel, a CV = 0 channel, or an ANSI channel, depending on the key distribution 
protocol to be used between the two cryptographic facilities supported by that channel. A CV channel therefore means 
that keys communicated via that channel will conform to the Control Vector Mode of Key distribution; a CV = 0 channel 
therefore means that keys communicated via that channel will conform to the Compatibility Mode of key distribution; an 
ANS channel therefore means that keys communicated via that channel will conform to the ANSI X9.17 Mode of key 

55 distribution. It is also convenient for the same key encrypting key to be used alternatively to define two channels (e.g., 
the KEK may be used as a CV Channel or a CV = 0 channel depending on the mode selected by the application (and 
ultimately reflected downward as a parameter at the crypto instruction level). 

The key distribution channel is a convenient concept, especially so since the key distribution method does not 
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necessarily reflect or depend on the method of key management implemented in the cryptographic facilities of the re- 
spective cryptographic devices. For example, key management could be control vector based or variant based, or some- 
thing else, whereas the key distribution method selected for key transmittal could be based on operational considerations 
such as who you're talking with at the moment, what key distribution method your communicating partner supports or 

5 requires, conformance to standards and practices, prior networking agreements, etc. 

A cryptographic facility in compliance with the CA (called a CA node) can establish a CV channel for communication 
with another CA node; it can establish a CV = 0 channel for communication with an IBM PCF, IBM CUSP/3848 or IBM 
4700 system node; or it can establish an ANSI channel for communication with another node supporting ANSI key 
distribution. The CA allows a mixed channel (CV or CV = 0) so that a single pair of KEKs can be shared, yet current 

10 applications running in compatibility mode and newly written applications running concurrently on a CA node can com- 
municate with another CA node using a single pair of KEKs. 

Key Types and Channel Types 

is Under the CA, every CV has a designated type and subtype, which are encoded fields in the control vector. The 

key distribution mode by which a key can legitimately be transmitted is also implicitly defined by its type/subtype, (note 
this implicit definition is used in lie of encoding the allowed channel types in a separate field in the control vector. This 
avoids the situation of redundant fields in the control vector.) The table in Fig. 70 provides a description of which channel 
types (i.e., modes of key distribution) can be used to communicate which CV type/subtypes. 

20 

Declared Key Distribution Mode (via the crypto instruction) 

In every instruction involving the export and import of keys (i.e., GKS, RFMK, and RTMK), the channel type (or key 
distrubition mode) must be declared via a parameter of the instruction (called key distribution mode, or MODE for short). 
25 Since the ANSI crypto instructions are separated from the other CA instructions, it is only necessary for the mode pa- 
rameter to distinguish CV from CV = 0. Thus, the mode parameter has the form mode = CV or mode - (CV = 0). 

Link Control Field 

30 For CV types = "kek" there is a CV field defined called Link Control. The link control field defines the allowed channel 

types that the KEK will operate under. The link control field is defined as below. 



Link Control Encoding 


Interpretation 


00 


not applicable 


01 


CV only 


10 


CV = 0 only 


11 


CV or CV = 0 



40 The "not applicable 0 field is defined to allow for present and future definition of KEK subtypes for which the link 

control field has no meaning (i.e., does not apply). For example, for CV type/subtype = "kek/ansi", link control has no 
meaning, and hence the field is always set to '00'. Note that link control = '11' means that KEK can be used to distribute 
keys using either a CV channel or a CV = 0 channel, depending on which distribution mode is specified in the crypto 
instruction. 

45 

Key Distribution Mode and Link Control 

The key distribution mode specified by the crypto instruction must always be an allowed mode, i.e., the link control 
field in the control vector of the KEK used to encrypt the transmitted key must permit/allow the specified key distribution 
so mode. The rules are described in the table of Fig. 71 . 

General Checking Rules 

The foregoing discussion has provided a set of rules which can now be summarised and discussed by way of an 
55 example. 

In every crypto instruction which results in the import or export of a key there are three parameters of interest: 
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10 



distribution mode specified in crypto instruction (call it M) 

link control field in the control vector of KEK used for key transmittal (call it L) 

CV type/subtype field in the control vector of the key transmitted (call it T) 

To decide whether the instruction can be executed, two checks are performed. (Other checks are performed as 
well, but are not germain to the present discussion.) The two checks are these: 

T must be permitted by M 
M must be permitted by L. 

i.e., the CV-type/subtype must be allowed to be transmitted via the key distribution mode specified by M and the mode 
specified by M must be a mode supported or allowed by L. 



15 



CV Type /Subtype 



Channel Type 
CV CV » 0 



ANSI 



20 



25 



Data/Privacy 
Data/MAC 
Data/Xlate 
Data/Comp 
Data/ ANSI 



y 
y 
y 
y* 

n 



n 
n 
n 

y 

n 



n 
n 
n 
n 

y 



30 



35 



KeK/Sender 

Kek/Receiver 

Kek/ANSI 



y 
y 

n 



n 
n 
n 



n 
n 

y 



40 



PIN/Encrypting 
PIN/Generating 



y 
y 



n 
n 



n 
n 



45 



iCV/Intennediate 
MAC lev 



50 



Key Part/ not 
applicable 



55 



NOTE: A key of type/subtype = data/comp (i.e., a compatibility mode data key can be communicated on a CV 
channel using a control vector or on a CV = 0 channel by stripping off the control vector 
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The Key Distribution Centre Concept 



The Key Distribution Centre (KDC) is the centre where keys are generated and distributed to other nodes of the 
network. The KDC cannot retain a local copy of these keys for use by itself, however. 

5 

- Distribute keys for two control vector nodes. 



Let C be the KDC centre that distribute keys for two nodes A and B. Also, let KKca be the cross domain key used 
to send keys C to A and kkcb be the cross domain key used to send keys from C to B. The GENKEY SET instruction, 
10 Export-Export mode can be used at the KDC to generate two copies of a key K and ship it to nodes A and B. Two two 
copies of the generated key K are encrypted and shipped under the form: e*KKca.C3(K) and e*KKcb.C4(K), where C3 
and C4 are the two control vectors specified the usage of the key K at node A and node B, respectively. The control 
vectors C3 and C4 are generated by CFAP based on user's specification at the generation time. The attributes of C3 
and C4 must follow the following rules: 

15 

— 1 . If the key K being distributed is a data key, then 



— the CV TYPE attribute of both must have main type = "data key" and both must have same subtype. 

20 — C3 and C4 may have the same or opposite USAGE attribute. For example, both nodes A and B can use the 

key K for both encryption and decryption (same usage attributes in C3 and C4), or node A can use the key K 
for Generate a MAC only, and node B can use the key K for verify a MAC only (different usage attributes in C3 
and C4). Fig. 34 describes all allowed combination of usage attributes for C3 and C4. 



25 - 2. If K is a key-encrypting key, then 

— If CV TYPE attribute in C3 is "KEK sender", then CV TYPE attribute in C4 must be "KEK receiver", and vice 
versa. That is, if the key K is used at node A to send keys then it must be used at node B to receive keys, and 
vice versa. 



30 



The LINK CONTROL attribute in both C3 and C4 must be the same. 



- 3. If K is a PIN-encrypting key, then the CV TYPE attribute in both C3 and C4 must be "PIN-encrypting key". 

35 Besides the above attributes, the CFAP also sets the EXPORT CONTROL attribute field in C3 and C4, depending 

on how the KDC wants the receiving nodes A and B control the further exports of this key K. Section "Control Vectors" 
describes the meaning of the EXPORT CONTROL field. 

At the receiving nodes A and B, the key K can be retrieved using the RTMK instruction. For example, A uses the 
RTMK to convert e*KKca.C3(K) to th encryption under its own master key (XORed with a control vector) for use on its 

40 system. 

NOTE: Keys shipped from a CV node to CV nodes by GENKEY SET instruction must use the CV channel. This 
implies that the LINK CONTROL field of the control vectors associated to cross domain keys KKca and KKcb must have 
the "CV only" or "CV or CV = 0" attribute. 

4S . Distribute keys for more than two control vector nodes. 

The main purpose of key distribution centres is to set up keys for two nodes to communicate. The need for distributing 
keys to more than two nodes seldom arises. However, it is possible for the KDC to distribute keys to more than two 
nodes, provided the control vectors associated with copies of the key being shipped are the same. 
50 Let KKci by the cross domain key used to send keys from node C, which acts as a KDC, to node i (i = 1 ,2,...n). The 

KDC can distribute a key K to n nodes (n]2) by: 

- 1. Using the KEYGEN instruction to generate a key K. K is encrypted under the KDC's master key KM. That is, K 
is of the form e*KM.C1(K), where C1 is the control vector that specifies the attributes of K. The EXPORT CONTROL 

55 field of C1 must have at least bit (bit 1 ) equal to "1 n so that K can be exported by RFMK. 

2. Using the RFMK function n times to convert e*KM.C1 (K) to the form e*KKci.C2(K) (with i = 1,2,...n), where C 2 is 
the new control vector specifies the attribute of the key K for use at the receiving node. This form is then shipped 
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to each node i. 

At each receiving node, the key K can be retrieved using the RTMK instruction. 

NOTE: In this application a local copy of the generated key K is available at the KDC. This should not be permitted, 
5 except in some application where no exposure is present. Thus, this application is very limited. 

An alternative, which eliminates the need for the KDC to have local copies of generated keys, can be implemented 
as follows: 

1 . The KDC uses the GENKEYSET instruction in the EXPORT-EXPORT mode to ship keys to one or two nodes. 

10 

- 2. The KDC re-import one copy of the key under a KEK that has the XLTKEY in and XLTKEY out attribute (assume 
CA allows this) and then translates that copy to the forms suitable for shipping to the remaining nodes. 

- Distribute keys to non-CV nodes 

15 

The KDC can distribute only data keys to two or more non-CV nodes. Distribution of other types of keys to non-CV 
nodes are not permitted. Data keys are first generated by the KEYGEN instruction and then distributed to non-CV nodes 
using the RFMK instruction, via the compatibility channel. This implies that the control vector associated to the KEK 
under which keys are shipped must have the M CV = 0" attribute for the LINK CONTROL field. Of course the EXPORT 

20 CONTROL field of the control vector associated with the generated data key must allow the data key to be exported 
(via the RFMK instruction), in order for the key to be distributed. 

NOTE: As in the above case, a local copy of the generated key K is available at the KDC. This should not be 
permitted, except in some limited application where no exposure is present. Thus, this application is very limited. The 
alternative that uses the combination of GENKEY SET / TRANSLATE KEY as proposed in the previous case can also 

25 be applied to this case. 

- Distribute keys to a control vector node and to a non-control-vector node 

The KDC can only distribute copies of a data key to both a CV node and a non-CV node. This is because only data 
30 keys can be distributed to non-CV node. The distribution can be done via the KEYGEN and RFMK combination or the 
GENKEY SET and RFMK combination. That is, the data key is first generated via the KEYGEN or GENKEY SET in- 
struction. One copy is then shipped to the CV node by the RFMK instruction or by the GENKEY SET (mode OP-EX) 
instruction itself (the CV channel should always be used.) The other copy is shipped to the non-CV node by the RFMK 
instruction, under the CV = 0 channel. 
35 Again, a local copy of the generated key is available to the KDC. The GENKEY SET / TRANSLATE KEY alternative 

may be implemented to avoid this problem. 

Key Translation 

40 Keys can be translated from encryption under one key-encrypting key to encryption under another key-encrypting 

key, using the TRANSLATE KEY function. This function is useful for the Key Translation Centre (KTC) environment, i.e., 
the environment where one or more nodes act as a node that translates keys for other nodes. For example, consider 
three cryptographic nodes A, B and C shown in Fig. 72. Besides its normal function as a cryptographic node, C ascts 
ad a KTC for A and B. A can communicate with C via cross-domain keys KEKac and KEKca. Likewise, B communicates 

45 with C via KEKbc and KEKcb. Assumes that A sends b data encrypted under data key KD, and A and B initially dont 
have common cross-domain keys to communicate. To decipher the data, B needs to know KD. Since A and B don't 
have common cross-domain keys, A cannot send encrypted keys that can be recovered at B. C can help B to receive 
KD by acting as a KTC. First, A sends C a copy of KD encrypted under KEKac (i.e., e*KEKac.C1(KD)). C invokes the 
TRANSLATE KEY function to translate e*KEKac.C1(KD) to e*KEKcb.C1 (KD) and then sends e*KEKcb.C1(KD) to B. At 

so node B, KD is recovered using the TRMK fucntion, and encrypted data can be deciphered using the decipher instruction 
with the received KD. 

Note that the TRANSLATE KEY instruction is designed in such a way that the KTC cannot retain a copy of the KD. 
Also, for security reasons, the CA does not allow mix and match of channels under which the keys being translated 
would come in (input channel) and come out (output channel). That is, if the key to be translated comes in under a CV 
ss channel then the translated key must come out in a CV channel; if the input channel is a CV = 0 channel then the output 
channel is a CV = 0 channel. This means that the control vectors of the KEKs associated to the input channel and output 
channels (KEKac and KEKcb in the above example) must have the LINK CONTGROL attribute agree with one of the 
valid combinations described in the TRANSLATE KEY instruction. 
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Export of Keys 

The export of a key is the encipherment of the key under a form suitable for sending to other nodes. That is, the 
key is encrypted under a key encrypting key shared between communicating nodes. 
5 A control vector system can exchange keys with other systems, whether the other systems have the control vector 

structure or not. Following are the rules defined by the CA with respect to the exportation of keys: 

• Export of Keys to CV System 

10 A control vector system can export data keys, key-encrypting keys, PIN keys, Intermediate CVs, key parts and 

tokens to other CV nodes. 

Keys are exported to CV nodes using the RFMK instruction or the GKS instruction, as discussed below. 

- Export of Keys With the RFMK Instruction 

15 

Keys used locally on a system can be exported to other CV nodes via the RFMK function if the export -control field 
in the control vectors of the keys allow it. Usually, these keys are either generated by the KEYGEN or GKS instruction, 
or received from another node. 

Let K be a key locally used on the system, encrypted in the form e*KM.C(K), where C is the control vector specifies 

20 the usage of A, created and supplied by CFAP. Whether K is generated on the system, or received from another node, 
or formed by a local transformation on an existing key (e.g., via the LCVA instruction), the decision on the export of K 
must be indicated in the EXPORT CONTROL of the control vector C. If the EXPORT CONTROL field of C allows K to 
be shipped to another CV node, then the RFMK can be used to export K. Let KK be the cross domain key used to ship 
keys from A to that node. The form of the key K to be shipped depends on the channel type under which it is shipped. 

25 The channel type is specified in the distribution mode of the RFMK instruction when it is invoked. For the RFMK instruction 
to be carried out, the distribution mode parameter of the RFMK instruction and the LINK CONTROL field of the control 
vector Ckk (associated to KK) must be one of the valid combinations specified in the table of Fig. 71 . 

- If distribution mode specifies the CV channel and the LINK CONTROL field of Ckk is either "CV" or "CV or CV = 0" 
30 then the combination is valid. K is exported in the form e*KK.C1 (K), where C1 is the control vector created by CFAP 

based on C and supplied to the RFMK instruction. 

» If distribution mode specifies the CV = 0 channel and the LINK CONTROL field of Ckk is either "CV = 0 U or "CV or 
CV = 0" then the combination is valid. K is exported under the form e*KK(K). The control vector is stripped off in 
35 this case. Note that only keys of the CV type data/compatibility is allowed to be shipped under the CV = 0 channel. 

Other keys are prohibited for security reasons (see the attack section). Existing applications (e.g., applications 
running on IBM CUSP/3848) that do not have control vector structures when ported to CS nodes, use the CV= 0 
channel to export keys. 

40 - Export of Keys With the GKS Instruction 

Keys can be exported to other CV nodes at generation time by the GKS instruction, in OP-EX mode, OP-IM mode, 
IM-EX mode and EX-EX mode. The modes of this instruction are described in "Electronic generation of keys ." In these 
modes, only the export copy is shipped to other nodes; the import copy is not shipped to other nodes, it is to be received 

45 later by the generating node itself; and the operational copy is for local use at the generating node. 

Unlike the RFMK instruction, the GKS instruction exports the export copy to another CV node under the CV channel 
only. This means that the LINK CONTROL field of the control vector associated to the key-encrypting key used that 
encrypt the export copy must have the "CV" or "CV = 0 n attribute. Using the same notation as above, the export copy 
is exported under the form e*KK.C1 (K). 

50 The GENKEY SET function provides a secure way to export keys to C V systems. It cannot be used directly to send 

keys to non-CV system. 

NOTE: When the RFMK or the GKS export a key under the CV channel, there are instances where the control 
vector associated to the key is not sent on the link. The receiving node must be able to correctly reconstruct the control 
vector in order to recover the right key. "Control vectors on the link" discusses procedures for setting up the control 
55 vector at the sending node and for reconstructing it at the receiving node when it is not sent on the link. 

When sending a key, the sending node has the option of allowing or disallowing the receiving node to further send 
the key to other nodes. 
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If the sending node does not want the receiving node to further ship the key to other nodes, CFAP sets the EXPORT 
CONTROL field of the control vector associated to the exported key to B'10\ 

If the sending node allows the receiving node to have control on further export of this key, CFAP sets bit 0 of the 
5 EXPORT CONTROL field to 0, the remaining bit is "don't care". When the receiving node receives the key, it can 

set the two bits of the EXPORT CONTROL field to any desired value. 

The CA permits the lowering of authority of the export control via the LCVA instruction. For example, after node A 
exporting a key K to another node, it may decide not to export it again. Node A can forbid the exporting of this key by 
10 applying the LCVA instruction on the key K and its control vector, reducing the export control authority down to B'00' or 
B'10' (no exporting). 

- Export of Keys to Non-CV Systems 

15 Only the RFMK instruction can be used to directly export keys to non-CV systems, provided the EXPORT CONTROL 

field of the associated control vector allows this. Also, only keys of CV type Data/compatibility can be exported to non-CV 
nodes, for security reasons. When the RFMK instruction exports a key to a non-CV node, only the CV = 0 channel can 
be used to ship the key. This means that the distribution mode parameter in the RFMK instruction must specify the CV 
= 0 channel, and the LINK CONTROL field of the control vector associated to the key-encrypting key used to ship the 

20 key must have the "CV = 0" or "CV or CV = 0" attribute. Using the same notation as above, the key is shipped to a 
non-CV node under the form e*KK(K). 

Import of Keys 

25 The import of a key is the re-encipherment of the key from the encryption under a key-encrypting key to the encryption 

under the master key of the receiving node. Keys that are in an importable form (i.e., encrypted under a key-encrypting 
key) are either sent from other nodes, or generated by the GKS instruction (in OP-IM mode or IM-EX mode). The RTMK 
instruction is the only instruction that can be used to import a key. 

30 -Import of Keys From CV Systems 

A CV system can receive a key of any CA key type sent from a CV node. The key sent from another CV node can 
arrive under a CV channel or a CV = 0 channel, and it must be received by the corresponding channel. The channel 
type is specified by the distribution mode parameter in the RTMK instruction when it is invoked. 

35 

If the distribution mode specifies the CV channel then the key is shipped and received under the CV channel. The 
key arrives from the sending node in the form e*KK.C3(K), where KK is the cross domain key shared between the 
communicating nodes and C3 is the control vector associated to the key K being shipped. The control vector C3 
may or may not be sent with the key. 

40 

When C3 is sent with the key, CFAP (at the receiving node) creates a new control vector, called C2, based on the 
sent control vector C3. CFAP supplies C2, C3 and other parameters to the RTMK instruction. The RTMK uses C3 
to recover the key K and then validates C2 and uses it to re-encipher the recovered key K to encipherment under 
the master key. The retrieved key is now in the form ready for local use, e*KM.C2(K). 

45 

- When the control vector C3 is not sent, CFAP (at the receiving node) first reconstructs C3, creates a new control 
vector C2 based on C3 and then supplies these and other parameters to the RTMK instruction. As above, the key 
is retrieved as e*KM.C23(K). 

50 CFAP may set the EXPORT CONTROL field of C2 different from that of C3, depending on the EXPORT CONTROL 

of C3: 

- If the EXPORT CONTROL of C3 is B'1 Y', where Y is 0 or 1, then CFAP must set the EXPORT CONTROL of C2 
equal to that of C3. If Y is 0, the sending node does not permit the receiving node to further export the key. If Y is 

55 1 , the key can be further exported to other nodes. 

- If the EXPORT CONTROL of C3 is B'0Y\ where Y is 0 or 1 , then CFAP can set the EXPORT CONTROL of C2 to 
any desired value. Thus, the EXPORT CONTROL of C2 and C3 can be different in this case. Observe that the 



89 



EP 0 356 065 B1 



second bit of the EXPORT CONTROL field of C3 does not control the further export of the received key. For example, 
if the EXPORT CONTROL of C3 is B'OY' = B*00' (i.e., Y = 0), the receiving node can allow the further export of the 
received key by setting the EXPORT CONTROL of C2 to B'OV or B'1V. 

5 NOTE: For the RTMK instruction to be carried out, the LINK CONTROL field of the control vector associated to KK 

must have the "CV or "CV or CV = 0' attribute. 

-- If the distribution mode specifies the CV = 0 channel then the key is shipped and received under the CV = 0 channel. 
The key arrives from the sending node in the form e*KK(K). At the receiving node, the key retrieved in the form 
io e*KM.C2(K), where C2 is the control vector associated to K, created by CFAP and supplied to RTMK. The EXPORT 

CONTROL field of C2 can be set to any desired value by CFAP. 

NOTE: Only the data/compatibility key type is sent and received under the CV = 0 channel. Therefore, C2 is of 
data/compatibility CV type and its usage attributes are limited to the combinations of the ENCIPHER, DECIPHER, GEN- 
15 MAD and VERMAC. Note also that for the TRMK instruction to be carried out, the LINK CONTROL field of the control 
vector associated to KK must have the "CV = 0° or "CV = 0" attribute. 

Receiving Keys From Non-CV System 

20 A CV system can receive only data/compatibility key type from a non-CV system. The sent key arrives from the 

sending node under a CV= 0 channel only (i.e., arriving in the form e*KK(K)). The manner in which this key is received 
is the same as in the case where the key is sent from a CV node under the CV-0 channel, described above. 

Control Vectors on the Link 

25 

Introduction to Communication Protocols for Transmission of Keys 

The Cryptographic Architecture includes communication protocols for the electronic transmission of cryptographic 
keys from one cryptographic facility to another. The CA communication protocol includes an on-the-like control vector 

30 definition and a specification of of the allowed protocols for using this control vector definition for the electronic trans- 
mission of cryptographic keys. 

Basically, the CA communication protocol provides a means for the cryptographic separation of electronically trans- 
mitted keys according to the key type of intended key usage. The communication protocol is such that if, during trans- 
mission a key of one type is substituted for a key of a different type, then the substituted key will fail to be properly 

35 recovered at the receiver. In that event, the sending and receiving cryptographic facilities will not have matching keys, 
and therefore communication wich such a key pair is not possible. At best, an adversary can disrupt the cryptographic 
system, but cryptographic attacks of the kind where an adversary attempts to force a receiving cryptographic facility to 
use a key in a way not intended by the sending cryptographic facility are thwarted. 

40 Key Management Requirements for Communicating CFs 

The CA Communication protocol has the following key management requirements for a communicating pair of 
cryptographic facilities, i and j: 

45 - 1 . j and j must share a key encrypting pair, KEKij and KEKji, where KEKij is used to send keys from i to j, KEKji is 
used to send keys from j to i, and KEKij and KEKji are both double length keys (128 bits). Optionally, i and j may 
share only KEKij for sending keys from i to j or KEKji for sending keys from j to i. Also optionally, i and j may share 
additional key encrypting keys or key pairs for purposes of electronic key distribution. These key-encrypting keys 
are commonly referred to as cross-domain keys. 

so 

2. At i and j, the keys KEKij and KEKji must be°marked B such that the use of these keys to electronically export and 
import keys (via GENKEYSET, RFMK, and RTMK) always requires the use of a control vector, as defined by this 
architecture. Additional optional shared key encrypting keys or key pair must also conform to this rule. 

55 NOTE: i and j may also share one or more key encrypting keys (or key pairs) for purposes of electronic key distri- 

bution, where the shared keys use a method not involving control vectors. This may be necessary in order to maintain 
compatibility with existing hardware or software facilities at i or j or both. However, the keys must be "marked" such that 
the use the keys to electronically export and import keys (via GENKEYSET, RFMK, and RTMK) specifically calls for 



90 



EP 0 356 065 B1 



10 



omitting the control vector, as defined by this architecture. 

NOTE; if control vectors are used internal to the cryptographic facility, and as defined by the common set of cryp- 
tographic functions, then a method for "marking" the KEK's (as required under item B b") is already specified. Otherwise, 
the "marking" must be provided by other means. 

Format for Electronic Transmission of Keys Using Control Vectors 

All electronically transmitted keys sent from a cryptographic facility, key generation facility, key distribution facility, 
or key translation facility, to a receiving cryptographic facility must be encrypted using the format described below: 
Let, 



15 



20 



*KEK = 1 28 bit key shared by the sending and receiving facilities for the purpose of transmitting keys from the sending 

to the receiving facility 
C = 64 bit control vector 

K = 64 bit key to be transmitted 

K1 ,K2 = 128 bit key to be transmitted 

Then, the following format is specified for single and double length keys: 



Key to be Transmitted 


Format of Transmitted Key 


K 

K1.K2 


e*KEK.C(K)K 

e*KEK.C(K1), e*KEK.C(K2) 



25 The Protocol for Compatibility 

The CA Communications protocol also defines a default control vector of 64 sero bits for purposes of maintaining 
compatibility with existing IBM cryptographic products such as 3848/CUSP, PCF and 4700. This communication mode 
allows keys to be transmitted and received using a control vector of ero (i.e., effectively without using a control vector). 
30 In this case, a key K is sent in the form eKEK(K) instead of in the form eKEK.C(K). 

Message Formats 

The CA Communication protocol permits encrypted keys to be transmitted using two formats. The information which 
35 is sent is assumed to be included within a message. The Communication protocol does not currently include a specifi- 
cation for message formats, as there may be many possible message formats which are acceptable or desirable de- 
pending on design requirements beyond the scope of this document to anticipate or define. The Communication protocol 
merely defines the information that must be sent in such a message depending on which format is selected: 

40 First Format: 



45 



• a. For 64 bit K: C, e*KEK.C(K) 

- b. For 128 bit K1.K2: C, e*KEK.C(K1), e*KEK.C(K2) 

Second Format: 



50 



- a. For 64 bit K: e*KEK.C(K) 

- b. For 1 28 bit K1 ,K2: e*KEK.C(K1 ), e*KEK.C(K2) 

NOTE: The degenerate case where CV = 0 is also covered by the above two formats. 
First Format - CV Transmitted 



The first format covers the case where the control vector is transmitted with the encrypted key. Since receiving 
55 cryptographic application or the cryptographic support program must always know for what purpose a received key is 
intended, the control vector may be found to be a convenient and compact way for all necessary key usage information 
to be conveyed from the sending station to a receiving station. Moreover, a received control vector may then be passed 
from the receiving application program to the cryptographic support program (e.g. IBM CUSP) and thence, depending 
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on how the RTMK function is implemented, directly from the cryptographic support program to the cryptographic facility 
(i.e., hardware) as a parameter of the RTMK function. Thus, management of the control vector by the software (i.e. 
CFAP) is apt to be less complex. 

s Second Format - CV Not Transmitted 

Two cases are possible with the second format. The first covers the case where the sending and receiving stations 
have made no prior agreement for reconstruction of the control vector. In this case, the receiving station follows a set 
of prescribed steps for reconstructing the control vector, which involves the use of certain default control vector values. 
10 The second case is where the sending and receiving stations have a prior agreement for reconstructing the control 
vector. In this case, the receiving station reconstructs the control vector according to the private previously established 
set of rules. 

The basic difference between the first and second cases of the second format is that in the first case, the receiving 
station reconstructs the control vector using certain vendor-provided default assumptions. In the second case, the re- 
15 ceiving station reconstructs the control vector according to a set of private agreed upon rules. 

Control Vector Specification 

The control vector specification for use on-the-link is the same as the internal control vector specification given in 
20 the Section entitled "Key Management". This means that the rules governing the creation and modification of control 
vectors, as specified by the CFAP macro definitions and the CF instructions, are also the same rules which apply 
on-the-link. These rules have been adopted to facilitate the smooth recovery of keys. The reader is reminded that key 
recovery via decryption requires that every bit in the control vector must be specified exactly the same as originally 
specified for encryption of the key. 
25 Basically, the rules are these: 

In general, CFAP has the responsibility for building all control vectors, and in some cases for checking/enforcing 
certain bits in the control vector. In general, the cryptographic facility has the responsibility for checking/enforcing 
bits in the control vector. 

30 

When a control vector is built, every bit in the control vector must be specified. Control vector bits are established 
as follows: 

- All reserved bits are set to zero. (This is easily accomplished by initially setting CV = 0. 
35 — The anti-variant bits, or fixed bits are set. 

- The remaining bits, except for the 8 parity bits (i.e., those defined under the architecture) are set from the 
parameter values specified by the application in the called CFAP macro or according to the macro specified 
default values. 

40 - if a key is transmitted from a sender to a receiver in the form eKEK.C(K), where C is not the degenerate control 
vector of 0 and C is not sent on the link, then the following control vector defaults are defined at the receiver: 

- default CV version = 0 

- default key type = "data key" 

45 - default export control = "0000°, i.e., unrestricted 

- For key type = "data key", default usage bits = "1100°, i.e., E and D 

- For key type = "KEK Sender", default target system = "00", i.e., "CV or CV = 0" default usage bits = "1111", i.e., 
unrestricted. 

- For key type = "KEK Receiver", default target system = "00", i.e., "CV or CV = 0" default usage bits = "11 ", i.e., 
50 unrestricted. 

- For key type = "PIN encrypting key", default usage bits = "010101", i.e., Reformat PIN Block key in and key 
out, and verify PIN. 

For key type = "PIN generating key", default usage bits = "01 ", i.e., verify PIN. These are the default values that 
should be used in the GENKEYSET, RFMK, XL ATE KEY, KEYGEN, EMK, and RTMK instructions. 

55 

- CA CV Defaults 
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10 



15 



What is Known 


What is Not Known 


What Values to Use 


Nothina 


If sender is CV svstsm 


use CV — 0 


Sender is CV System 


CV Version number 


use Version = 00 


Sender is CV System 


Reserved Bits 


use all binary zeros 


Sender is CV System 


CV Type 


use DATA type 


C V type is DATA 


Attributes 


E D 


CVtype is PINE 


Attributes 


RPB-I RPB-0 VP 


CV type is PING 


Attributes 


VP 


CV type is KEKS 


Attributes 


GKS-LR GKS-RR RFMK XLT-0 


CV type is KEKS 


Target System 


CV or CV = 0 


CVtype is KEKR 


Attributes 


RTMK XLT-I 


CVtype is KEKR 


Target System 


CV or CV = 0 


CV type is KEYP 


Attributes 


(no defaults) 


CV type is IICV 


(no Attributes exist) 





20 



Storage of Keys 



25 



30 



40 



45 



50 
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All keys external to the cryptographic facility are maintained in encrypted form, by encrypting them under a key 
formed by the XORing a control vector with the master key. 

Encrypted keys stored external to the cryptographic facility may optionally be stored together with the control vector 
used to encrypt the stored key. But the storage of the clear control vector is not necessary as long as the control vector 
can be dynamically reconstructed on the basis of other information stored with the key or from the context in which the 
encrypted key is used. 

All generated and imported keys are encrypted and stored in mass key storage outside the Cryptographic Facility. 
The key storage is further partitioned into two separate areas: KKDS (KEK Data Set) and DKDS (Data Key Data Set). 
The distinction between these two storage areas is made due to the fact that different mechanisms are employed in the 
CA to manage the data keys and key-encrypting keys (and PIN related keys). 

Encrypted key encrypting keys, PIN encrypting keys and PIN generating keys can be stored in a KKDS and ad- 
dressed via non-secret key labels. 

Encrypted data keys can be stored in a DKDS, or clear data keys can be stored in the cryptographic facility, provided 
that applications accessing these keys do so using secret token values which have about 56 secret independent bits. 
Additional security can be provided to the encrypted keys stored in the DKDS by Exclusive ORing each encrypted key 
with a mask which is equal to a 1-way function of the secret token used to access the encrypted data key. 

Fig. 73 illustrates the KKDS with several KEK entries. Every key-encrypting key (denoted here as KEKi) consists 
of two 64 bit key halves and is encrypted and stored in the form of two 64 bit halves. The first half is the encryption of 
the left half of the key (KEKiL) under the key formed by KM Xor CL, where CL is the control vector associated to KEKiL. 
Likewise, the second half is the encryption of the right half of the key (KEKiR) under the key formed by KM XOR CR, 
where CR is the control vector associated to KEKiR. The control vectors CL and CR are the same except in the value 
of the KEY FORM field, which indicates whether the key half is the left half or the right half. 

NOTE: If the key KEKi is short (i.e., single length) then it is still stored in the form of two 64 bit halves. However, the 
left half and the right half are equal since KEKiL = KEKiR and CL = CR = C. The coupling of the left key half and the 
right key half to the corresponding control vector that indicates the left or right position of the key half, is essential to 
defend against the type of attack knows as 'key half replicating' attack. In this kind of attack, suppose there is no such 
coupling, the opponent substitutes one encrypted half by the other half (i.e., he replicates one key half) so that the two 
halves of the encrypted key are equal. He can perform cryptographic operations on the key half to exhaust search half 
of the key. He then repeats the process for the other key half. In essence, the work factor of a long key is now reduced 
to the magnitude of the work factor of a short key. 

For any cryptographic operation, the CFAP fetches the encrypted keys from the key storage and supplies it to the 
instruction being executed. These keys are decrypted and used by the instruction inside the CF only. The keys never 
appear outside the CF in the clear. 

NOTE: For most of the key management instructions who usually operate on key-encrypting keys, when each in- 
struction is invoked, it must be invoked twice in order to operate or produce the two key halves of double length key-en- 
crypting keys. Each invocation will operate on and or produce each key half of the key-encrypting keys. Therefore, CFAP 
or application must provide appropriate values of parameters (such as encrypted key half and associate control vector 
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with proper value for the KEY FORM field, etc.) to ensure correct result. 

In high volume systems where keys are accessed frequently, cache mechanisms can be implemented to speed up 
the access of keys. 

s Outside Versus Insider Attacks 

It is the intent of the key management to provide security against outsider attacks and certain insider attacks. 

ANSI X9.17 Key Management 

w 

It is the intent of key management to be able to coexist with the ANSI X9. 1 7 key management without loss of security 
to either key management. 

Compatibility With Current Products 

15 

Compatibility with current products, e.g., IBM 3848/CUSP, is handled on two levels. A combination of KEYGEN, 
RTMK, and RFMK will allow a data key to be produced in 4 different forms which correspond directly to the 4 different 
forms that can be produced by the GENKEY macro currently available in IBM 3848/CUSP. For example, to be compatible 
with the IBM 3848/CUSP in the generation of a session key, the KEYGEN function can be used to create a random 

20 number that is considered as a session key encrypted under the master key. Then the RFMK function can be used to 
ship it to other nodes. Similarly, a file key can be compatibly generated by first using the KEYGEN instruction to obtain 
a random number, considered as the file key encrypted under a file master key, and then the RTMK function can be 
used to convert this into a file key encrypted under the master key for use on the system. The RTMK and RFMK functions 
effectively allow a special case of import and export data keys where the control vector is 64 zero bits (i.e., no control 

25 vector). 

Software Interface 

The CFAP provides the Applications Interface to the Cryptographic Facility. The interface may be implemented in 
30 the form of macros or subroutine calls and may include a Key Storage Manager component, which handles storage and 
retrieval of keys stored on a Key Storage Data Set. 

ANSI X9.17 Key Management 

35 - ANSI Node Architecture 

Fig. 74 illustrates the basic components of an ANSI X9.17 node. This architecture is based on the basic System 
Diagrams shown in Figs. 1 , 2 and 3. 

The ANSI Key Manager is an application program which utilises the cryptographic services of the Cryptographic 
40 Facility Access Program (CFAP) to generate, import and export keys and to authenticate Cryptographic Service Mes- 
sages (CSMs). CSMs are ANSI X9. 1 7 defined messages used to exchange keying material or related information among 
communicating ANSI nodes. 

The CFAP uses the services of a Key Storage Manager to access ANSI keys which are stored external to the 
Cryptographic Facility (CF). The storage area is known as the Key Storage. Such keys are always stored encrypted 
45 under the system master key (KM) with an appropriate Control vector. The CF provides the primitive cryptographic 
functions (encipher, decipher, MAC generation, etc.) to the CFAP. The CF also provides limited internal storage for the 
clear KM and a few working keys. 

The ANSI Key Manager uses the system-provided Communications Services (e.g., VTAM or device-drivers) to send 
and receive CSMs to/from other ANSI nodes. 

so 

- ANSI Node Functional Interfaces 

Fig. 75 illustrates some of the functional interfaces between components in an ANSI node. The ANSI Key Manager 
accesses CFAP services via Macro calls. CFAP retrieves and stores ANSI keys via function calls to the Key Storage 
ss Manager. The Key Storage Manager in turn uses system I/O services (or memory access instructions) to retrieve/store 
the requested keys from secondary (or primary) storage, known as the Key Storage. The Key Storage Manager may 
also verify key integrity on behalf of the CFAP. Each key entry record in the Key Storage may consist of an identifying 
label, the encrypted key, the explicit Control Vector (CV) under which it is stored, the Send and Receive Counters (for 
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10 



so 



55 



KEKs only), and other key- related parameters. The CFAP references CF instructions to perform primitive cryptographic 
functions. 

- Key Distribution Environments 

ANSI X9. 17 supports three basic environments for key distribution: Point-to-Point, Key Distribution Centre and Key 
Translation Centre. 

Point-to-Point (P-P) 



In this environment one node (say, Node B) wishes to communicate with another node (Node A) but does not have 
the ability to generate nor access data keys. It is assumed, however, that Nodes A and B already share a manually-in- 
stalled key encrypting key, (*)KKab. (The notation '(*)' means either a single-length key-encrypting key, KK, or a dou- 
ble-length key -encrypting key, *KK.) Node a generates one or more keys as requested by Node B, stores a local copy 

15 and returns the duplicates encrypted under (*)KKab to Node B. 

Fig. 76 shows two ANSI nodes in a Point-to-Point environment. The nodes share a key-encrypting key, *KKab, 
which is stored along with the associated send and receive counters in each node's Key Storage. Note that e*KM.C1 
(*KKab) is actually stored as e*KM.C1 (KKabl), e*KM.C1(KKabr), the left-most and right-most 64 bits of *KKab respec- 
tively. Other key-related parameters may also be present in the Key Storage record for this key. 

20 a sequence of CSM transmissions representing Point-to_Point key distribution is shown: Node B requests one or 

more keys from Node A via an RSI (Request Service Initiation), Node A returns the requested key(s) via a KSM (Key 
Service Message), and Node B acknowledges receipt with an RSM (Response Service Message). Other CSM trans- 
actions are similarly defined in the Point-to-Point environment to support error handling and key discontinuance requests. 
For example, Node B may request a single data encrypting key, KD, from Node A. Then the message format for a 

25 possible RSI for this request is as follows: 

CSM(MCL7RSI 
RCV/NodeA 
ORG/NodeB 
30 SVR/ 

EDC/aKDX(MCL/RSI ... SVR/)) 

NOTE: aKDj(X) represents the Message Authentication Code (MAC) of X using key KDj. KDX represents a special 
case of KDj: the fixed, non-secret hex key '01 23456789 ABC DEP. 
35 Node A generates the single KD, encrypts it under *KKab shared with Node B and offset with the Send Counter 

associated with *KKab, and forms the KSM to be sent to Node B: 

CSM(MCUKSM 
RCV/NodeB 
40 ORG/NodeA 

KD/e*KKAB+Send_Ctr_*KKab(KD) 
CTP/Send_Ctr_*KKab 

MAC/aKD(MCL/KSM ... CTP/Send_Ctr_*KKab)) 

45 Here, e*KKab+Send_Ctr_*KKab(KD) is the ciphertext resulting from the triple encryption of KD under the key formed 

by offsetting *KKab with the current value of its Send Counter, denoted Send_Ctr_*KKab. Offsetting is described in 
Section 7.4 of ANSI X9. 17-1 985. 

Node B receives the KSM, extracts the KD/ field, recovers the new KD and stores it under Node B's master key in 
the Key Storage, then formulates the RSM as an acknowledgement to Node A: 



CSM(MCURSM 

RCV/NodeA 

ORG/NodeB 

MAC/aKD(MCL7RSM ... ORG/Node B)) 
Key Distribution Centre (KDC) 

Fig. 77 shows three ANSI nodes in a KDC environment. 
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In this environment a Node B wishes to communicate with a Node A with which it shares no keys. It is assumed, 
however, that Node B shares a manually-installed key-encrypting key, (*)KKbc, with Node C, serving as a Key Distribution 
Centre. Furthermore, Node C shares a manually-installed key-encrypting key, (*)KKbc, with Node C, serving as a Key 
Distribution Centre. Furthermore, Node C shares a manually-installed key-encrypting key, (* )KKac, with Node A. Node 
5 A passes Node B's key request onto Node C, which generates two duplicate sets of keys. The first set is encrypted 
under (*)KKac and the second set under (*)KKbc. Both sets are then shipped back to Node A. Node A recovers and 
stores the first set of keys, and passes the second set onto Node B. Node B similarly recovers and stores its key set. 

— Key Translation Centre (KTC) 

TO 

Fig. 78 shows three ANSI nodes in a KTC environment. 

In this environment a Node B wishes to communicate with a Node A with which it shares no keys. It is assumed 
that Node A has the capability to generate or access keys, and shares a manually-installed key-encrypting key, (*)KKac, 
with Node C, which serves as a Key Translation Centre. 
is Furthermore, Node C shares a manually-installed key-encrypting key, (*)KKbc, with Node B. Node A generates the 

requested key set, stores a local copy, and sends a duplicate set encrypted under (*)KKac to Node C. Node C recovers 
the key set, re-encrypts the keys under (*)KKbc, and returns the translated key set to Node A. Node A passes the key 
set onto Node B for its recovery and storage. 

20 - Key Distribution Scenarios 

The following section summarises the key distribution scenarios defined in ANSI X9. 1 7. The scenarios are presented 
in tabular form, one for key-encrypting keys and one for data encrypting keys. 

Furthermore, each table is divided into three environments: point-to-point, key translation centre, and key distribution 
25 centre. Only one environment applies for each cryptographic exchange. In general, a distribution scenario for a given 
environment is presented left-to-right, top-to-bottom. Where options exist, a given column will be split horizontally, re- 
flecting the choice and outcome for a selected option. The CA does not support all ANSI X9.17 options. Unsupported 
options are marked "no" in the "SUP?' column. 

The columns are defined as follows: 

30 

— ENV is the ANSI X9. 17 distribution environment: Point-to-Point, Key Distribution Centre, or Key Translation Centre 
NOD is the party in the distribution scenario, where by convention, node B is typically the initial key requester, node 
A is the requestee, and KTC or KDC is the supporting Key Centre 

~ RCVS specifies the key type (KK, *KK, KD or KDmac, a temporary MAC key) of a key received by NOD 
35 - FROM is the party that generated or translated the received key; X via Y denotes that the X passes the key through 
node Y to NOD 

— UNDR 1 is the single or double-length KEK under which the key is received; subscripts denote the nodes sharing 
the KEK (a is node A, b is node B, c is the Key Centre); offsetting is implicit; notarisation is denoted by keys of the 
form (*) KNxy; 'new* denotes a new KEK accompanying the received key 

40 - GENS specifies the key type (KK, *KK, KD, or KDmac) of a key generated by NOD 

-- STORES is the form of the received or generated key to be stored at NOD; KK//KK denotes replication of a single 
length KK to form a pseudo-double length KEK; (temp) denotes temporary storage only: this key is retained only 
for the purposes of processing CSMs 

UNDR 2 is the key under which the received or generated key is to be stored at NOD; ordinarily of the form KMx, 
45 denoting the Master Key of node X (a is node A, b is node B, c is the Key Centre); Control Vector variation is implicit 

— SNDS is the form of the generated or translated key which will be sent to the node specified by TO 

— TO is the node to which the generated or translated key will be sent; X via Y denotes that NOD sends the key to X 
through node Y; X and Y denotes that NOD sends the key to X and Y (under different KEKs) 

— UNDR 3 is the single or double-length KEK under which the generated or translated key will be sent; offsetting is 
50 implicit; notarisation is denoted by KEKs of the form (*)KNxy; KK1 and KK2 denote that the key is sent under two 

different KEKs corresponding to the destinations in column "TO 1 ; 'new 1 denotes a new KEK accompanying the gen- 
erated or translated key 

SUP? denotes whether the CA implementation of ANSI at NOD will support this option of the scenario 
55 - *KK Distribution 

The table summarising the cryptographic exchange of key-encrypting keys is shown in Fig. 79. 



96 



EP 0 356 065 B1 

- KD Distribution 

The table summarising the cryptographic exchange of data keys is shown in Fig. 80 and Fig. 81 . 
s - Instruction Set to Support ANSI X9.1 7 



1. The following new instructions are added to the CA to support ANSI X9.17: 

10 

- ANSI Partial Notarise a Key (APNOTR) 

- ANSI Re-encipher From Master Key (ARFMK) 

- ANSI Re-encipher to Master Key (ARTMK) 

- ANSI Translate a Key (AXLTKEY) 

15 ~ ANSI Combine Data Keys (ACOMBKD) 

2. The following existing CA instructions are needed to support ANSI X9. 1 7: 

- Keygen 

20 An extension to the Keygen instruction is added to allow control vectors of the type ANSI KEK. 

- Encipher 

No change required. 
~ Decipher 

No change required 
25 — Genmac 

No change required 

- Vermac 

No change required 

30 Design Considerations 

- Offsetting and Notarisation 

Offsetting of keys in the process of translating a key-encrypting key (KEK) by exclusive-ORing the key with a stored 
35 counter. Offsetting is always used to transform a KEK prior to encryption of a key be that KEK. 

Notarisation is a method for sealing KEKs with the identities of the sender and intended recipient. Ordinarily, a 
notarising key KN is formed by computing a notary seal as a function of the KEK, the identities of the sender and receiver, 
and the offset counter for this KEK, then exclusive-ORing NS with the KEK. Since the counter value for a given KEK 
increments over time, NS would normally be computed afresh each time KEK notarisation is desired. 

But since a given ANSI KEK is always associated with exactly one sender and receiver, NS and thus, KN, is a 
function of only one dynamic quantity: the offset counter for the KEK. Therefore we can define a function, APNOTR, to 
use the static quantities of the KEK (the key itself and the sender and receiver identities) to compute a partial notarising 
key, KN'. KN' can be then stored with its corresponding KEK, retrieved when notarising is desired, and simply offset 
with the current counter value to form KN. APNOTR is described in "ANSI Create Partial Notarising Key (APNOTR). B 
45 The advantage of this approach is to avoid recomputing KN every time it is needed, but more importantly, it reduces 

the complexity of the CA functions. Instead of having to support both notarising and offsetting of KEKs in the CA functions 
used to import, translate, or export keys, only offsetting must be provided. If notarisation must be performed, the partially 
notarised form of the KEK is provided to the appropriate CA function. Otherwise, the KEK itself is provided. Regardless, 
the CA function performs off -setting on the specified key prior to suing it to encrypt or decrypt a key. 

so 

-ANSI X9.17 Subsets 

The KK and KD distribution scenarios shown in Figs. 79, 80 and 81 include all ANSI X9.17-defined options. The 
last column in each table, labelled 'SUP?', indicates whether CA support is provided for this option. 
55 At this time, the only ANSI distribution options not supported by the CA are those related to the generation of a 

single length key-encrypting keys. For example, in Fig. 79, an ANSI Node A in the Point-to-Point environment may 
generate a new single-length KK and ship it to an ANSI Node B under four (*)KK options: KKab, *KKab, KNab, or *KNab. 
However, the CA does not support generation of single-length KKs. Thus the 'SUP?' column for the four ANSI distribution 



97 



EP 0 356 065 B1 

options is marked 'NO'. 

In order to provide ANSI compatibility with non-CA nodes, the CA does support importation of new single-length 
KKs. For example, using the same table as above, an ANSI Node B may receive a single-length KK from an ANSI Node 
A under one of four forms of another (*)KK: KKab, *KKab, KNab, or *KNab. The 'SUP?' column for each option is marked 
5 'YES' to indicate support for each option. Note that imported single-length KKs are always stored in replicated form (i.e. 
128 bits as KK//KK). 

The single-length KK restriction impacts KD distribution options as well. ANSI X9.17 requires that if a new (*)KK is 
distributed with one or two new KDs, then the KDs will by encrypted under the new (*)KK. But since CA does not support 
single-length KK generation, the option to distribute new KDs under a new single-length KK is not supported. An example 
10 of this is shown in Fig. 80, Point-to-Point for Node A. The table shows that KD distribution under a new single-length 
KKab is not supported. 

ICV Management 

is ANSI X9.17 supports distribution of encrypted or plaintext 64-bit Initial Chaining values (ICVs or IVs). A CA macro, 

GENIV, will be defined which supports generation and storage of ICVs. ICVs will be stored in the Key Storage alongside 
the KD with which it is to be used. GENIV will use the CF instruction KEYGEN to generate a 64-bit clear, non-parity 
adjusted random number, RN. GENIV will store RN and and ICV_Mode flag in the Key Storage entry for KD. The 
ICV_Mode flag indicates whether RN should be treated as en enciphered ICV or a plaintext ICV. If the mode is enci- 

20 phered, RN must be deciphered using key KD before using it as an ICV in the ENCIPHER or DECIPHER functions. The 
ANSI X9.17 RTR and KSM messages are used to distribute the generated ICV and a similar flag indicating whether the 
ICV is enciphered or plaintext. GENIV will also be used at the receiver to store the received ICV into Key Storage. The 
receiver of course must specify the ICV_Mode based on the flag in the RTR or KSM message. 

2* Acronyms and Abbreviations 





00 


Condition code 


30 


OA 


Cryptographic Architecture 




CV 


Control Vector (nothing to do with ICV or OCV) 




CBC 


Cipher Block Chaining. An encryption mode of the Data Encryption Standard. 




DED 


Decipher, Encipher and Decipher 




DEA 


Data Encryption Algorithm 


35 


DES 


Data Encryption Standard 




ECB 


Electronic Code Book. An encryption mode of DES. 




EDE 


Encipher, Decipher and Encipher 




ICV 


Input Chaining Value (Nothing to do with CV) 




KDx 


Data Key (x = integer) 


40 


KEKx 


Key Encrypting Key (x = integer) 




KM 


Master Key 




KMN 


New master key 




KMO 


Old master key 




KPEx 


Pin Encrypting Key (x = integer) 


45 


KPGx 


Pin Generation Key (x = integer) 




KPVx 


(Pin Validation Key (x = integer) 




KKNI 


Immediate notarised key, 128 bits 




KKNIL 


Left 64 bits of KKNI 




KKNIR 


Right 64 bits of KKNI 


50 


KDmac 


Temporary MAC key for ANSI message 




MAC 


Message Authentication Code 




MDC 


Modification Detection Code 




OCV 


Output Chaining Value 




PIN 


Personal Identification Number (used with ATMs) 



55 
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Algorithms 

- Encode and Decode Algorithm 

5 The Encode and Decode instructions use the ECB (Electronic Code Book) mode of the DES. There is no chaining 

or feedback in this mode. Fig. 82 illustrates the operation of the ECB mode of encryption and decryption. 

- Cipher Algorithm 

10 The Enciphering/Deciphering Algorithm is the National Bureau of Standards Data Encryption Standard (DES) or 

equivalents the American National Standards Institute Data Encryption Algorithm (ANSI DEA) X9.92-1 981 . Cipher Block 
Chaining (CBC) is done as specified in ANSI Cryptographic Modes of Operation X9. 106-1 983. Figs. 83 and 84 show 
the CBC mode of operation Encipher and Decipher operations respectively. 

15 - Message Authentication (MAC) 

The Financial Institution Message Authentication Standard (Wholesale ANSI X9.9) as referenced in References 
(6), defines a process for authentication of messages from originator to recipient. This process is independent of com- 
munication media and payment systems. 

20 The authentication process includes the computation, transmission, and verification of a Message Authentication 

code (MAC). The MAS = C is based on either of the complete message text or a selected message elements of the text. 
The MAC is added to the message by the originator and is transmitted to the recipient. The message or message 
elements are accepted as authentic by the recipient if the same algorithm and secret key produce a MAC identical to 
the received MAC. The security of the authentication process is directly dependent on the security afforded to the secret 

25 key. 

The MAC is generated as shown in Fig. 85. The authentication algorithm as described in this standard may be 
implemented using either the 64 bit CBC or CFB modes of operation as described in ANSI X3. 106-1 983. Both modes 
shall be initialised so as to produce equivalent MAC's. KEY is a 64 bit key, and A1 through An are 64 bit data blocks. 
Initial chaining value is '0* in this standard and CBC mode of operation should be implemented as shown in Fig. 85. if 
30 an An is less than 64 bits, then '0's are appended (padded) to the right of the remaining bits. The left most 32 bits of 
(on) are taken as the MAC. 

NOTE: The capability should exist to generate and to process 48 to 64 bit MAC's. For these cases, the left most 48 
bits or the entire final output (On) are taken as the MAC. 

The algorithm describes the MAC generation for binary data. Message authentication for "Coded Character Sets" 
35 should be implemented as described in the ANSI X9. 9-1 986, the MAC algorithm is invoked after the characters are 
represented in binary data. 

- MDC Algorithms 

40 Two MDC algorithms exist: 

1 . MDC_2 - Two encipherments per 8 byte input data block 

2. MDC_4 - Four encipherments per 8 byte input data block 

45 Two different algorithms allow the invoker to trade a 50% performance improvement for a slight decrease in security 

depending on his applications. 

- MDC_2 (text) 

so - 1 . Pad the input text wtih X'FP to a multiple of 8 bytes. 

- 2. Partition the input text into [n] 8 byte blocks T8[1 ] to T8[n]. 

- 3. If n = 1 then set n = 2 and T8[2] = 8 bytes of x'00*. 

- 4. Set intital values of KD1 and KD2 (see below). 

- 5. For[i] = 1,2,....n: 

55 

— a. MDCOP(KD1.KD2,T8[i],T8[i] 

— b. KD1 : = OUT1 

— c. KD2 : = OUT2 
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— d. end of FOR loop 

6. Output of MDC_2 is the 1 6 byte MDC : = (KD1 // KD2). 
5 - MDC_4 (text) 

- 1 . Pad the input text with X'FP to a multiple of 8 bytes. 

- 2. Partition the input text into [n] 8 byte blocks T8[1 ] to T8[n] 
-- 3. If n = 1 then set n = 2 and T8[2] = 8 bytes of x'00' 

10 - 4. Set initial values of KD1 and KD2 (see below) 

- 5. For[i] = 1,2,...^: 

— a. MDCOP(KD1,KD2,T8[i],T8[i]) 

— b. KD1int: = OUT1 
15 — c. KD2int : = OUT2 

— d. MDCOP (KD1int.KD2int.KD2.KD1) 

— e. KD1 : = OUT1 

— f . KD2 : = OUT2 

— g. end of FOR loop 

20 

- 6. Output of MDC_4 is the 1 6 byte MDC : = (KD1 // KD2) 
The initial values of KD1 and KD2 are as follows: 

25 ~ 1 . KD1 : = X , 5252525252525252' 

- 2. KD2 : = X , 2525252525252525' 

- Notarisation Algorithms 
30 - Using KK 

Le KK be the key which is to be used to compute the notarisation key. Then: 

KKR = KK + FM1 (+ is exclusive or operation, and FM1 is first 8 bytes of from ID) 
35 KKL = KK + T01 (T01 is the first 8 bytes of to ID) 

NS1 = eKKR(T02) T02 is the second 8 bytes of to ID) 
NSr = eKKL(FM2) FM2 is the second 8 bytes of from ID) 

NS = (left most 32 bits of NS1 ) // right most 32 bits of NSr) + CT (CT is a 64 bit counter associated with KK) 
KN = KK + NS 

40 

KN is a notarised key used to encrypt either a KD or KK. 
Using *KK 

45 Let *KK be the key which is to be used to computer the notarisation key. Then: 

*KK = KK1 // KKr 

KKR = KKr + FM1 (+ is exclusive or operation, and FM1 is first 8 bytes of from ID) 
KKL = KK1 + T01 (T01 is the first 8 bytes of to ID) 
50 NS1 - eKKR(T02)+ CT (T02 is the second 8 bytes of to ID and CT is a 64 counter associated with *KK) 
NSr = eKKL(FM2)+CT (FM2 is the second 8 bytes of from ID) 
*KN = (KK1 + NS1 ) // (KKr + NSr) 



*KN is a notarised key used to encrypt either a KD or (*)KK. 
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Standards and Definitions 
- Standards 



15 



20 



25 



30 



ANSI X2.92- 1981 
ANSI X9.106 -1983 
ANSI X9.2- 198X 



ANSI X9.8- 1982 



ANSI X9.9 - 1986 



ANSI X9.17-1985 



ANSI X9.19-198X 



ANSI X9.23- 198X 



ISO DIS 8583 



ISO DIS 8720 
ISO DP 8730 



ISO DP 8731 



40 ISO DP 8732 



45 



ISO DP 9546 



"Data Encryption Algorithm ". 
"Modes of PEA Operation ". 

'Interchange Message Specification for Debit and Credit Card Message Exchange Among 
Financial Institutions ". This standard specifies a common interface by which bank card origi- 
nated messages relating to a financial transaction may be interchanged between private sys- 
tems. It specifies message structure, format and content, data elements and values for data 
elements. 

"American National Standard for Personal Identification Number (PIN) Management and 
Security ". This standard establishes standards and guidelines for the management and security 
of the Personal Identification Number's (PIN's) life cycle. 

"American National Standard for Financial Institution Message Authentication (Wholesale) 
". This standard established a method to authenticate financial messages (wholesale), including 
fund transfers (e.g. wire transfers), letters of credit, security transfers, loan agreements and 
foreign exchange contracts. 

"Financial Institution Key Management (Wholesale) '. This standard establishes methods (in- 
cluding the protocol) for the generation, exchange and use of cryptographic keys of authentica- 
tion and encryption. 

"Financial Institution Retail Message Authentication 11 . This standard establishes a method to 
authenticate financial messages for retail transactions. 

"Encryption of Wholesale Financial Messages ". This standard established a method to encrypt 
wholesale financial messages in order to provide confidentiality (e.g., wire transfers, letters of 
credit, etc.) 

"Bank Card Originated Messages - Interchange Message Specifications - Content for Fi- 
nancial Transactions ". This international standard specifies a common interface by which bank 
card originated messages relating to a financial transaction may be interchanged between pri- 
vate systems. It specifies message structure, format and content, data elements and values . 
"Message Authentication " 

"Banking - Requirements for Standard Message Authentication (wholesale) ". This interna- 
tional standard specifies a technique for protecting the authenticity of messages passing be- 
tween financial institutions by means of a Message Authentication Code (MAC). 
"Banking - Approved Algorithms for Message Authentication - Part 1 : DES-1 Algorithm ". 
This part of ISO 8731 deals with the Data Encryption Algorithm (DEA-1) as a method for use in 
the calculation of the Message Authentication Code (MAC). Part-2 Other non- DEA Algorithms 
"Banking - Key Management Wholesale " This international standard specifies methods for the 
management of keying material used for the encryption and authentication of messages ex- 
changed in the course of wholesale financial transactions. 

"Personal Identification Number Management and Security Part 1 - PIN Protection Principles 
and Technique " This standard specifies the minimum security measures required for effective 
PIN management. Standard means of interchanging PIN data are provided. 



50 



Instructions and Macros Summary Chart 

Figs. 86, 87 and 88 summarise the equations for each of the CA instructions. 
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25 Claims 



1. A method for validating that key management functions requested for a cryptographic key have been authorised 
by the originator of the key in a data processing system which processes cryptographic service requests for the 
management of cryptographic keys which are associated with control vectors defining the functions which each key 

30 is allowed by its originator to perform, comprising the steps of: 

receiving a cryptographic service request for performing a key management function on a cryptographic key in 
a cryptographic facility (4) having a secure boundary (6) through which passes an input path and an output 
path (8); 

35 

receiving a control vector (figure 10) associated with the cryptographic key and checking (14) that the control 
vector authorises the key management function which is requested by the cryptographic service request; and 

signalling (20) that the key management function is authorised and initiating the performance of the requested 
40 key management function with the cryptographic key. 

2. A method as claimed in claim 1 , which further comprises the step of: 

storing in a storage means (22) the cryptographic key in an encrypted form in which the cryptographic key is 
encrypted under a storage key which is a logical product of the associated control vector and a master key (18). 

45 

3. A method as claimed in claim 2, which further comprises: 

the cryptographic service request being for the recovery of the cryptographic key from the storage means; 

50 receiving the encrypted form of the cryptographic key from the storage means and decrypting the encrypted 

form under the storage key which is a logical product of the associated control vector and the master key. 

4. A method as claimed in any preceding claim, wherein the storge key is the exclusive-OR product of the associated 
control vector and the master key. 



55 



A method as claimed in any preceding claim, wherein the associated control vector is stored with the encrypted 
form of the cryptographic key in the storage means. 
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A method as claimed in any preceding claim, wherein the associated control vector includes fields defining author- 
ised types of cryptographic functions including key management functions, data encryption/decryption functions 
and PIN processing functions, and the key management functions type is designated from the following: - 

export control and usage; - link control which specifies whether a control vector associated with a cryptographic 
key can be omitted from transmission from the data processing system to a remote data processing system 
connected thereto due to the characteristics of the remote date processing system; 
whether the key associated therewith can be processed by an ANSI -type data processing system. 

A method as claimed in any preceding claim, wherein the associated control vector includes fields enforcing the 
separation of key encryption keys based on two mutually exclusive intended uses. 

A method as claimed in claim 7, wherein the mutually exclusive intended uses are designated from the following: - 
for notarised and non-notarised keys; 

for first type key encrypting keys using control vectors and second type key encrypting keys not using control 
vectors; 

for first type key encrypting keys used only by senders and second type key encrypting keys used only by 
receivers. 

for first type key encrypting keys used for translation of keys for shipment without allowing export of existing 
data keys stored under a master key and second type key encrypting keys used for translation of keys for 
shipment with allowance for export of existing data keys stored under a master key. 

for first type key encrypting keys which can be generated for export only and second type key encrypting keys 
which can be generated for local operational use and for export; 

for first type key encrypting keys which can be used in translation without allowing local operational use and 
second type key encrypting keys which can be used in translation and which are allowed for local operational 
use; 

for first type key encrypting keys which can be used in re-encipher from master key operations and second type 
key encrypting keys which cannot be used in re-encipher from master key operations. 

A method as claimed in any preceding claim, wherein the associated control vector includes a field to designate 
whether the cryptographic key is a single length key or a double length key. 

A method as claimed in any preceding claim,, for performing a generate key set function, which further comprises: 
supplying a random number to the cryptographic process 

receiving over the input path a cryptographic service request for the generation of a key pair from the random 
number with associated first and second control vectors C3 and C4 and outputting in response thereto, an 
authorisation signal to the cryptographic process that the function of generating a key pair from the random 
number is authorised; 

in response to the authorisation signal, outputting the random number as a first generated key in an encrypted 
form in which the random number is encrypted under a key which is a logical product of the first associated 
control vector C3 and a first key K1 ; and 

in response to the authorisation signal, outputting the random number as a second generated key in an 
encrypted form in which the random number is encrypted under a key which is a logical product of the second 
associated control vector C4 and a second key K2. 

A method as claimed in claim 10, for producing two keys which are operational in the data processing system, 
wherein the first and second keys K1 and K2 are the master key, enabling operational usage within the local data 
processing system. 

A method as claimed in claim 1 0, for producing a first generated key which is only operational in the data processing 
system which is a local data processing system, and a second generated key which can be exported to a remote 
data processing system connected to the local system, wherein the first key K1 is the master key, enabling opera- 
tional usage within the local data processing system and the second key K2 is a key encrypting key KEK2 with an 
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associated control vector C2 and the control vector C2 authorises exportation to the remote data processing system. 

13. A method as claimed in claim 10, for producing a first generated key which can be exported to a first remote data 
processing system connected to the data processing system which is a local data processing system and a second 

5 generated key which can be exported to a second remote data processing system connected to the local system, 

wherein the first key K1 is a key encrypting key KEK1 with an associated control vector C1 and the control vector 
C1 authorises exportation to the first remote data processing system and the second key K2 is a key encrypting 
key KEK2 with an associated control vector C2 and the control vector C2 authorises exportation to the second 
remote data processing system. 

10 

1 4. A method as claimed in claim 1 0, for producing a first generated key which is only operational in the data processing 
system which is a local data processing system, and a second generated key which can be imported from a utilisation 
device connected to the local system, wherein the first key K1 is the master key, which only authorises operational 
usage within the local data processing system and the second key K2 is a key encrypting key KEK2 with an asso- 

is ciated control vector C2 and the control vector C2 authorises importation from the utilisation device to the local 

system. 

15. A method as claimed in claim 10, for producing a first generated key which can be imported from a utilisation device 
connected to the data processing system which is a local data processing system and a second generated key 

20 which can be exported to a remote data processing system connected to the local system, wherein the first key K1 

is a key encrypting key KEK1 with an associated control vector C1 and the control vector C1 authorises importation 
from the utilisation device and the second key K2 is a key encrypting key KEK2 with an associated control vector 
C2 and the control vector C2 authorises exportation to the second remote data processing system. 

25 16. A method as claimed in any preceding claim, for performing a re-encipherment from master key function, which 
further comprises checking means checking the control vector C1 associated with the key encrypting key KEK to 
ensure that the re-encipher from master key function is authorised and checking that the control vector C2 associated 
with the key K authorises that the key K may be allowed to be exported using the re-encipher from master key 
function. 

30 

1 7. A method as claimed in claim 1 6, wherein the associated control vector C3 selectively enables the remote processor 
to re-export the cryptographic key K. 

18. A method as claimed in claim 16, wherein the control vector C1 associated with the key encrypting key KEK is 
35 checked to ensure that the re-encipher to master key function is authorised. 

19. A method as claimed in claim 16, wherein the control vector C3 received from the remote data processing system, 
selectively permits further re-exportation of the key K from the local data processing system. 

40 20. A method as claimed in claim 16, wherein the control vector C2 is selectively set by the local data processing system 
to permit further re-exportation of the cryptographic key K from the local data processing system. 

21 . A method as claimed in any preceding claim, for performing a translate key function, including checking the control 
vector C1 associated with the import key encrypting key KEK1 , to ensure that KEK1 is authorised as an import key 

45 encrypting key in the translate key function and the control vector C2 associated with the export key encrypting key 

KEK2 so as to ensure that KEK2 is authorised as an export key encrypting key in the translate key function. 

22. A method as claimed in any of claims 1 to 9, for performing a re-encipherment from master key function with a 
reduction in the export authority for the recipient, including checking the control vector C1 associated with the key 

50 encrypting key KEK to ensure that the re-encipher from master key function is authorised and the control vector C2 

associated with the key K authorises that the key K may be allowed to be exported using the re-encipher from 
master key function. 

23. A method as claimed in any preceding claim, wherein the associated control vector includes a field defining link 
55 control which specifies whether a control vector associated with a cryptographic key can be omitted from transmis- 
sion from the data processing system to a remote data processing system connected thereto due to the character- 
istics of the remote data processing system. 
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24. A method as claimed in any preceding claim, wherein the associated control vector includes a field to designate 
whether the cryptographic key is a single length key or a double length key. 

25. A data processing system which processes cryptographic service requests for the management of cryptographic 
5 keys which are associated with control vectors defining the functions which each key is allowed by its originator to 

perform, comprising: 

a cryptographic facility (4) having a secure boundary (6) through which passes an input path (8) for receiving 
the cryptographic service requests, cryptographic keys and their associated control vectors, and an output path 
10 (8) for providing responses thereto, there being included within the boundry (6) a cryptographic instruction 

storage (10) coupled to the input path, a control vector checking means (14) and a cryptographic processing 
means (16) coupled to the instruction storage, and a master key storage (18) coupled to the processing means 
(16), for providing a secure location for executing key management functions in response to the received service 
requests; 

15 

the cryptographic instruction storage (10) receiving over the input path (8) a cryptographic service request for 
performing a key management function with a cryptographic key; 

the control vector checking means (14) having an input coupled to the input path (8) for receiving a control 
20 vector (figure 1 0) associated with the cryptographic key and an input connected to the cryptographic instruction 

storage (10), for receiving control signals to initiate checking that the control vector authorises the key man- 
agement function which is requested by the cryptographic service request; and 

the control vector checking means (14) having an authorisation output (20) connected to an input of the cryp- 
ts tographic processing means (16), for signalling that the key management function is authorised, the receipt of 
which by the cryptographic processing means (16) initiates the performance of the requested key management 
function with the cryptographic key. 



30 Patentanspruche 

1 . Ein Verfahren zur Uberprufung, daQ fur einen Chiffrierschlussel angeforderte Schlusselverwaltungsf unktionen vom 
Urheber des Schlussels in einem Datenverarbeitungssystem autorisiert worden sind, das Chiffrierserviceanforde- 
rungen zur Verwaltung von ChiffrierschlQsseln verarbeitet, denen Steuervektoren zugeordnet sind, welche die Funk- 

35 tionen, zu denen jeder Schlussel von seinem Urheber ermachtigt wurde, definieren, wobei das Verfahren folgende 

Schritte umfaGt: 

Empfangen einer Chiffrierserviceanforderung zur Ausfuhrung einer Schlusselverwaltungsfunktion an einem 
Chiffrierschlussel in einer Chiffriervorrichtung 4 mit einer sicheren Grenze 6, durch die ein Eingangspfad und 
40 ein Ausgangspfad 8 verlauft; 

Empfangen eines dem Chiffrierschlussel zugeordneten Steuervektors (Fig. 10) und Prufung, ob der Steuervek- 
tor zu der durch die Chiffrierserviceanforderung angeforderte Schlusselverwaltungsfunktion berechtigt; sowie 

45 Signalisieren 20, daG die Schlusselverwaltungsfunktion autorisiert ist, und Starten der angeforderten Schlus- 

selverwaltungsfunktion mit dem ChiffrierschlOssel. 

2. Ein Verfahren gemaG Anspruch 1 , das auGerdem folgende Schritte umfaGt: 

Speichem des Chiffrierschlussels in verschlusselter Form in einer Speichervorrichtung 22, wobei der Chiffrierschlus- 
50 sel unter einem Speicherschlussel verschlusselt wird, der ein logisches Produkt des zugeordneten Steuervektors 

und eines Hauptschlussels 18 ist. 

3. Ein Verfahren gemaG Anspruch 2, bei dem auGerdem 

55 die Chiffrierserviceanforderung die Rekonstruktion des Chiffrierschlussels aus der Speichervorrichtung betrifft; 

die verschlusselte Form des Chiffrierschlussels aus der Speichervorrichtung empfangen und unter dem Spei- 
cherschlussel, der ein logisches Produkt des zugeordneten Steuervektors und des Hauptschlussels ist, dechif- 
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friert wird. 

Ein Verfahren gemaG den vorausgehenden Anspruchen, bei dem der Speicherschlussel das Exklusiv-ODER-Pro- 
dukt des zugeordneten Steuervektors und des Hauptschlussels ist. 

Ein Verfahren gemaG den vorausgehenden Anspruchen, bei dem der zugeordnete Steuervektor mit der verschlus- 
selten Form des Chiffrierschlussels in der Speichervorrichtung gespeichert wird. 

Ein Verfahren gemaG den vorausgehenden Anspruchen, bei dem der zugeordnete Steuervektor Felder enthalt, in 
denen autorisierte Arten von Chiffrierfunktionen einschlieGlich Schlusselverwaltungsfunktionen, Datenverschlusse- 
lungs- bzw. Datenentschlusselungsfunktionen und PIN-Verarbeitungsfunktionen definiert sind, und bei dem die Art 
der Schlusselverwaltungsfunktionen durch folgende Angaben naher bezeichnet wird: 

Exportkontrolle und Verwendung; 

Verbindungssteuerung, die angibt, ob ein einem Chiffrierschlussel zugeordneter Steuervektor bei der Ubertra- 
gung vom Datenverarbeitungssystem an ein angeschlossenes femes Datenverarbeitungssystem aufgrund der 
Merkmale des fernen Datenverarbeitungssystems ubergangen werden kann; 

Angabe, ob der zugeordnete Schlussel von einem ANSI-Datenverarbeitungssystem verarbeitet werden kann. 

Ein Verfahren gemaG den vorausgehenden Anspruchen, bei dem der zugeordnete Steuervektor Felder enthalt, in 
denen die Trennung von Schlusselchiffrierschlusseln auf der Basis zweier sich gegenseitig ausschlieGender Ver- 
wendungszwecke erzwungen wird. 

Ein Verfahren gemaG Anspruch 7, bei dem die sich gegenseitig ausschlieGenden Verwendungszwecke folgender 
Liste entnommen sind: 

fur beglaubigte und nicht begtaubigte Schlussel; 

fur eine erste Art von Schlusselchiffrierschlusseln mit Steuervektoren und eine zweite Art von Schlusselchif- 
frierschlusseln ohne Steuervektoren; 

fur eine nur von Sendern verwendete erste Art von Schlusselchiffrierschlusseln und eine nur von Empfangern 
verwendete zweite Art von Schlusselchiffrierschlusseln; 

fur eine erste Art von Schlusselchiffrierschlusseln, die fur die Umwandlung von Schlusseln f Or die Versendung 
ohne die Moglichkeit zum Export vorhandener unter einem Hauptschlussel gespeicherter Datenschlussel ver- 
wendet wird, und fur eine zweite Art von Schlusselchiffrierschlusseln, die fur die Umwandlung von Schlusseln 
fur die Versendung mit der Moglichkeit zum Export vorhandener unter einem HauptschlOssel gespeicherter 
Datenschlussel verwendet wird; 

fur eine erste Art von Schlusselchiffrierschlusseln, die nur fur den Export generiert werden konnen, und eine 
zweite Art von Schlusselchiffrierschlusseln, die fur eine lokale Verwendung und fur den Export generiert werden 
konnen; 

fur eine erste Art von Schlusselchiffrierschlusseln, die bei der Umwandlung ohne die Moglichkeit zur lokalen 
Verwendung benutzt werden konnen, und eine zweite Art von Schlusselchiffrierschlusseln, die bei der Um- 
wandlung benutzt werden konnen, und bei denen eine lokale Verwendung zulassig ist; 

fur eine erste Art von Schlusselchiffrierschlusseln, die bei der Wiederverschlusselung von Hauptschlusselope- 
rationen verwendet werden konnen, und eine zweite Art von Schlusselchiffrierschlusseln, die nicht fur die Wie- 
derverschlusselung von Hauptschlusseloperationen verwendet werden konnen. 

Ein Verfahren gemaG den vorausgehenden Anspruchen, bet dem der zugeordnete Steuervektor ein Feld enthalt, 
in dem angegeben ist, ob der Chiffrierschlussel einfache Oder doppelte Lange besitzt. 

Ein Verfahren gemaG den vorausgehenden Anspruchen zur Ausfuhrung einer Schlusselgruppengenerierungs- 
funktion, das auBerdem folgende Schritte umfaBt: 

Erzeugung einer Zufallszahl fOr den VerschlusselungsprozeG; 

Empfangen einer Chiffrierserviceanforderung uber den Eingangspfad, um mit den ersten und zweiten Steuer- 
vektoren C3 und C4 aus der Zufallszahl ein Schlusselpaar zu generieren und als Antwort darauf ein Berechti- 
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gungssignal an den ChiffrierprozeG zu senden, das besagt, daG die Funktion zur Generierung eines Schlus- 
selpaares aus der Zufallszahl berechtigt ist; 

als Antwort auf das Berechtigungssignal Ausgabe der Zufallszahl als erster generierter Schlussel in einer chif- 
5 frierten Form, in der die Zufallszahl unter einem Schlussel chiffriert wird, der ein logisches Produkt des ersten 

zugeordneten Steuervektors C3 und eines ersten Schlussels K1 ist; 

als Antwort auf das Berechtigungssignal Ausgabe der Zufallszahl als zweiter generierter Schlussel in einer 
chiffrierten Form, in der die Zufallszahl unter einem Schlussel chiffriert wird, der ein logisches Produkt des 
10 zweiten zugeordneten Steuervektors C4 und eines zweiten Schlussels K2 ist. 

11. Ein Verfahren gemaG Anspruch 10 zur Erzeugung zweier Schlussel, die im Date nverarbe it ungssy stem verwendbar 
sind, wobei der erste Schlussel K1 und der zweite Schlussel K2 den Hauptschlussel bilden, der die Verwendung 
im lokalen Datenverarbeitungssystem ermoglicht. 

75 

12. Ein Verfahren gemaG Anspruch 10 zur Erzeugung eines ersten generierten Schlussels, der nur in dem Datenver- 
arbeitungssystem benutzt werden kann, das ein lokales Datenverarbeitungssystem ist, und eines zweiten gene- 
rierten Schlussels, der an ein an das lokale System angeschlossenes femes Datenverarbeitungssystem exportiert 
werden kann, wobei der erste Schlussel K1 der Hauptschlussel ist, der die Benutzung im lokalen Datenverarbei- 

20 tungssystem ermoglicht, und der zweite Schlussel K2 ein Schlusselchiffrierschlussel KEK2 mit einem zugeordneten 

Steuervektor C2, und der Steuervektor C2 zum Export an das feme Datenverarbeitungsystem berechtigt. 



13. Ein Verfahren gemaG Anspruch 10 zur Erzeugung eines ersten generierten Schlussels, der an ein erstes an das 
lokale Datenverarbeitungssystem angeschlossenes femes Datenverarbeitungssystem exportiert werden kann, und 

2S eines zweiten generierten Schlussels, der an ein zweites an das lokale Datenverarbeitungssystem angeschlossenes 

femes Datenverarbeitungssystem exportiert werden kann, wobei der erste Schlussel K1 ein Schlusselchiffrier- 
schlussel KEK1 mit einem zugeordneten Steuervektor C1 ist und der Steuervektor C1 zum Export an das erste 
feme Datenverarbeitungssystem berechtigt, und wobei der zweite Schlussel K2 ein Schlusselchiffrierschlussel 
KEK2 mit einem zugeordneten Steuervektor C2 ist und der Steuervektor C2 zum Export an das zweite feme Daten- 

30 verarbeitungssystem berechtigt. 



14. Ein Verfahren gemaG Anspruch 10 zur Erzeugung eines ersten generierten Schussels, der nur in dem Datenver- 
arbeitungssystem benutzt werden kann, das ein lokales Datenverarbeitungssystem ist, und eines zweiten gene- 
rierten Schlussels, der von einem an das lokale System angeschlossenen Benutzergerat importiert werden kann, 
35 wobei der erste Schlussel K1 der Hauptschlussel ist, der ausschlieGlich zur Benutzung im lokalen Datenverarbei- 

tungssystem berechtigt, und der zweite Schlussel K2 ein Schlusselchiffrierschlussel KEK2 mit einem zugeordneten 
Steuervektor C2 ist und der Steuervektor C2 zum Import vom Benutzergerat in das lokale System berechtigt. 



1 5. Ein Verfahren gemaG Anspruch 1 0 zur Erzeugung eines ersten generierten Schlussels, der von einem an das lokale 
40 Datenverarbeitungssystem angeschlossenen Benutzergerat importiert werden kann, und eines zweiten generierten 

Schlussels, der an ein an das lokale System angeschlossenes femes Datenverarbeitungssystem exportiert werden 
kann, wobei der erste Schlussel K1 ein Schlusselchiffrierschlussel KEK1 mit einem zugeordneten Steuervektor C1 
ist und der Steuervektor C1 zum Import vom Benutzergerat berechtigt, und wobei der zweite Schlussel K2 ein 
Schlusselchiffrierschlussel KEK2 mit einem zugeordneten Steuervektor C2 ist und der Steuervektor C2 zum Export 
45 an das zweite feme Datenverarbeitungssystem berechtigt. 



1 6. Ein Verfahren gemaG den vorausgehenden Anspruchen zur Durchfuhrung einer Wiederverschlusselung vom Haupt- 
schlussel, das auGerdem uber Mittel zur Prufung des dem Schlusselchiffrierschlussel KEK zugeordneten Steuer- 
vektors C1 verfugt, um sicherzustellen, daG die Wiederverschlusselung vom HauptschlOssel autorisiert ist, und zur 
Prufung, ob der dem SchlOssel K zugeordnete Steuervektor C2 zum Export des Schlussels K anhand der Wieder- 
verschlusselung vom Hauptschlussel berechtigt. 



17. Ein Verfahren gemaG Anspruch 16, bei dem der zugeordnete Steuervektor C3 dem fernen Prozessorselektiv ermog- 
licht, den Chiffrierschlussel K wiederzuexportieren. 

55 

18. Ein Verfahren gemaG Anspruch 16, bei dem der dem Schlusselchiffrierschlussel KEK zugeordnete Steuervektor 
C1 gepruft wird, um sicherzustellen, daG die Funktion zur Wiederverschlusselung zum Hauptschlussel autorisiert ist. 
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19. Ein Verfahren gemaG Anspruch 16, bei dem der vom femen Datenverarbeitungssystem empfangene Steuervektor 
C3 selektiv einen weiteren Wiederexport des Schlussels K vom lokalen Datenverarbeitungssystem erlaubt. 



20. Ein Verfahren gemaG Anspruch 16, bei dem der Steuervektor C2 vom lokalen Datenverarbeitungssystem selektiv 
5 so gesetzt wird, daG ein weiterer Wiederexport des Chiffrierschlussels K vom lokalen Datenverarbeitungssystem 

erlaubt ist. 



21. Ein Verfahren gemaG den vorausgehenden Anspruchen zur Durchfuhrung einer Schlusselumwandlungsfunktion 
wobei der Steuervektor C1, der dem Importschlussel-Chiffrierschlussel KEK1 zugeordnet ist, gepruft wird, um 
10 sicherzustellen, daG KEK1 als Importschlussel-Chiffrierschlussel bei der Schlusselumwandlungsfunktion autorisiert 

ist, und wobei der Steuervektor C2, der dem Exportschlussel-Chiffrierschlussel KEK2 zugeordnet ist, gepruft wird, 
um sicherzustellen, daG KEK2 als Exportschlussel-Chiffrierschlussel bei der Schlusselumwandlungsfunktion auto- 
risiert ist. 



is 22. Ein Verfahren gemaG Anspruch 1 bis 9 zur Durchfuhrung einer Funktion zur Wiederverschlusselung vom Haupt- 
schlOssel mit einer geringeren Exportberechtigung fur den Empfanger, wobei der dem Schlusselchiffrierschlusse! 
KEK zugeordnete Steuervektor C1 gepruft wird, um sicherzustellen, daG die Funktion zur Wiederverschlusselung 
vom Hauptschlussel autorisiert ist, und wobei der dem Schlussel K zugeordnete Steuervektor C2 zum Export des 
Schlussels K mittels der Funktion zur Wiederverschlusselung vom Hauptschlussel berechtigt. 



20 



25 



23. Ein Verfahren gemaG den vorausgehenden Anspruchen, bei dem der zugeordnete Steuervektor ein Feld enthalt, 
in dem die Verbindungssteuerung definiert wird, die festlegt, ob ein einem Chiffrierschlussel zugeordneter Steuer- 
vektor bei der Ubertragung von Datenverarbeitungssystem an ein daran angeschlossenes femes Datenverarbei- 
tungssystem aufgrund der Merkmale des fernen Datenverarbeitungssystems ubergangen werden kann. 

24. Ein Verfahren gemaG den vorausgehenden Anspruchen, bei dem der zugeordnete Steuervektor ein Feld enthalt, 
in dem angegeben ist, ob der Chiffrierschlussel einfache oder doppelte Lange besitzt. 



25. Ein Datenverarbeitungssystem, das Chiffrierserviceanforderungen fur die Verwaltung von Chiffriersch I Ossein ver- 
30 arbeitet, denen Steuervektoren zugeordnet sind, welche die Funktionen definieren, zu deren Aufuhrung die einzel- 

nen SchlOssel von ihrem Urheber ermachtigt wurden, und das folgende Komponenten umfaGt: 

eine Chiffriervorrichtung 4 mit einer sicheren Grenze 6, durch die ein Eingangspfad 8 zum Empfang der Chif- 
frierserviceanforderungen, der Chiffrierschlussel uod der zugeordneten Steuervektoren sowie ein Ausgangs- 
35 pfad 8 fur Antworten darauf verlauft, wobei sich innerhalb der Grenze 6 ein an den Eingangspfad gekoppelter 

Speicher 1 0 fur Chiffrieranweisungen, ein Mittel 1 4 zur Prufung der Steuervektoren und ein an den Anweisungs- 
speicher gekoppeltes Chiffrierverarbeitungsmittel 16, sowie ein an das Verarbeitungsmittel 16 gekoppelter 
Hauptschlusselspeicher 18, der einen sicheren Ort fur die Ausfuhrung von Schlusselverwaltungsfunktion en als 
Antwort auf die empfangenen Serviceanforderungen bietet, befindet; 



40 



wobei der Chiffrieranweisungsspeicher 10 uber den Eingangspfad 8 eine Chiffrierserviceanforderung zur 
Durchfuhrung einer Schlusselverwaltungsfunktion mit einem Chiffrierschlussel empfangt; und 



das Mittel 1 4 zur Prufung der Steuervektoren einen an den Eingangspfad 8 gekoppelten Eingang zum Empfang 
45 eines dem Chiffrierschlussel zugeordneten Steuervektors (Fig. 10) enthalt, sowie einen an den Chiffrieranwei- 

sungsspeicher 10 gekoppelten Eingang zum Empfang von Steuersignalen zum Starten der Prufung, ob der 
Steuervektor zu der von der Chiffrierserviceanforderung angeforderte Schlusselverwaltungsfunktion berechtigt; 



das Mittel 1 4 zur Prufung der Steuervektoren einen an einen Eingang des Chiffrierverarbeitungsmittels 1 6 ange- 
so schlossenen Autorisierungsausgang 20 besitzt, uber den signalisiert wird, daG die Schlusselverwaltungsfunk- 

tion autorisiert ist, deren Empfang durch das Chiffrierverarbeitungsmittel 16 die Ausfuhrung der angeforderten 
Schlusselverwaltungsfunktion mit dem Chiffrierschlussel startet. 



5S Revendlcations 



1. Proced6 pour valider le fait que des fonctions de gestion de code demand6es pour un code cryptograph ique ont 
ete autoriees par I'emetteur d code, dans un systeme de traitement de donnees qui traite des demandes de service 
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cryptographique pour la gestion de codes cryptograph iques qui sont associes a des vecteurs de commande defi- 
nissant les fonctions que I'emetteur de chaque code lui permet, comprenant les etapes suivantes: 

reception d'une demande de service cryptographique pour effectuer une fonction de gestion de code sur un 
code cryptographique dans une installation cryptographique (4) comportant une limite de securrte (6) par I'inter- 
mediaire de laquelle passe un trajet d'entree et un trajet de sortie (8); 

reception d'un vecteur de commande (figure 10) associe au code cryptographique et controlant (14) la fait que 
le vecteur de commande autorise la fonction de gestion de code qui est demandee par la demande de service 
cryptographique; et 

signalisation (20) du fait que la fonction de gestion de code est autorisee et initiation de la performance de la 
fonction de gestion de code demandee avec le code cryptographique. 

Procede selon la revendication 1 , qui comprend en outre les etapes suivantes: 

stockage dans un moyen de stockage (22) du code cryptographique sous une forme crypt6e dans laquelle le 
code cryptographique est crypte sous un code de stockage qui est le produit logique du vecteur de commande 
associe et d'un code principal (18). 

Procede selon la revendication 2, qui comprend en outre: 

le fait que la demande de service cryptographique est le retablissement du code cryptographique en provenance 
du moyen de stockage; 

la reception de la forme cryptee du code cryptographique en provenance du moyen de stockage et le decryptage 
de la forme cryptee sous le code de stockage qui est le produit logique du vecteur de commande associe et 
du code principal. 

Proced6 selon Tune quelconque des revendications precedentes, dans lequel le code de stockage est le produit 
OU exclusif du vecteur de commande associe et du code principal. 

Precede selon Tune quelconque des revendications precedentes, dans lequel le vecteur de commande associe est 
stocke avec la forme cryptee du code cryptographique dans le moyen de stockage. 

Procede selon Tune quelconque des revendications precedentes, dans lequel le vecteur de commande associe 
comporte des champs definissant des types autorises de fonctions cryptograph iques comportant des fonctions de 
gestion de code, des fonctions de cryptage/decryptage de donnees et des fonctions de traitement PIN, et le type 
de fonctions de gestion de code est designe a partir de ce qui suit: 

commande et usage d'exportation; - la commande de liaison sui specif ie si un vecteur de commande associe 
a un code cryptographique peut etre supprime de la transmission entre le systeme de traitement de donnees 
et un systeme de traitement de donnees situ6 a distance qui lui est connecte etant donn6 les caracteristiques 
du systeme de traitement de donnees situe a distance; 

si le code associe a celui-ci peut etre traite par un systeme de traitement de donnees de type ANSI. 

Procede selon Tune quelconque des revendications precedentes, dans lequel le vecteur de commande associe 
comporte des champs forgant la separation des codes de cryptage de code sur la base de deux usages attendus 
exclusifs mutuellement. 

Procede selon la revendication 7, dans lequel les usages attendus mutuellement exclusifs sont designes a partir 
de ce qui suit: 

pour des codes notarises et non notarises; 

pour des codes de cryptage de code d'un premier type utilisant des vecteurs de command et des codes de 
cryptage de code d'un second type n'utilisant pas de vecteurs de commande; 

pour des codes de cryptage d'un premier type utilises uniquement par des expediteurs et des codes de cryptage 
de code d'un second type utilises uniquement par des recepteurs. 

pour des codes de cryptage de code d'un premier type utilises pour la transformation de codes pour la desti- 
nation sans permettre I'exportation de codes de donnees existants stockes sous un code principal et des codes 
de cryptage de code d'un second type utilises pour la transformation de codes pour la destination avec per- 
mission d' exporter les codes de donnees existants stockes sous un code principal. 
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pour des codes de cryptage de code d'un premier type qui peuvent etre generes pour rexportation uniquement 
et des codes de cryptage de code d'un second type qui peuvent etre gener6s pour un usage operationnel local 
et pour rexportation; 

pour des codes de cryptage de code d'un premier type qui peuvent etre utilises en transformation sasn permettre 
d'usage operationnel local et des codes de cryptage de code d'un second type qui peuvent etre utilises en 
transformation et qui sont permis pour un usage operationnel local; 

pour des codes de cryptage de code d'un premier type qui peuvent etre utilises pour le re-chrff rage a partir 
d'operations du code principal et des codes de cryptage de code d'un second type qui ne peuvent pas dtre 
utilises pour le re-chiffrage a partir d'operations du code principal. 

9. Precede selon I'une quelconque des revendications precedentes, dans lequel le vecteur de commande associe 
comporte un champ pour designer si le code cryptographique est un code d'une seule longueur ou un code de 
longueur double. 

is 10. Precede selon I'une quelconque des revendications precedentes, pour effectuer une fonction de generation cTeta- 
blissement de code, qui comporte en outre: 

Papplication d'un nombre aleatoire au traitement cryptographique 

la reception sur le trajet d'entree d'une demande de service cryptographique pour la generation d'une paire de 
20 codes a partir du nombre aleatoire avec des premier et second vecteurs de commande associes C3 et C4 et 

delivrance en reponse a ceci, d'un signal d'autorisation au traitement cryptographique du fait que la fonction 
de generation d'une paire de codes a partir du nombre aleatoire est autorisee; 

en reponse au signal d'autorisation, delivrance du nombre aleatoire sous la forme d'un premier code g6n6r6 
sous une forme cryptee dans lequel le nombre aleatoire est crypte sous un code qui est le produit logique du 
25 premier vecteur de commande associe C3 et d'un premier code K1 ; et 

en reponse au signal d'autorisation, delivrance du nombre aleatoire sous la forme d'un second code genere 
sous une forme cryptee dans lequel le nombre aleatoire est crypte sous un code qui est le produit logique du 
second vecteur de commande associe C4 et d'un second code K2. 

30 11. Precede selon la revendication 1 0, pour produire deux codes qui sont operationnels dans le systeme de traitement 
de donnees, dans lequel les premier et second codes K1 et K2 sont le code principal, permettant I'usage operationnel 
dans le systeme de traitement de donnees local. 

12. Precede selon la revendication 10, pour produire un premier code g6n6re qui est uniquement operationnel dans le 
35 systeme de traitement de donnees qui est un systeme de traitement de donnees local, et un second code genere 

qui peut etre exports vers un systeme de traitement de donnees situ6 a distance connects au systeme local, dans 
lequel le premier code K1 est le code principal, permettant un usage operationnel dans le systeme de traitement 
de donnees local et le second code K2 est un code de cryptage de code KEK2 avec un vecteur de commande 
associe C2 et le vecteur de commande C2 autorise rexportation vers le systeme de traitement de donn6es situ6 a 
40 distance. 

13. Precede selon la revendication 10, pour produire un premier code genere qui peut dtre exporte vers un premier 
systeme de traitement de donnees situ6 a distance connecte au systeme de traitement de donnees qui est un 
systeme de traitement de donnees local et un second code g6ner6 qui peut etre exporte vers un second systeme 

45 de traitement de donnees situe a distance connecte au systeme local, dans lequel le premier code K1 est un code 

de cryptage de code KEK1 avec un vecteur de commande associe C1 et le vecteur de commande C1 autorise 
I'exportation vers le premier systeme de traitement de donnees a distance et le second code K2 est un code de 
cryptage de code KEK2 avec un vecteur de commande associe C2 et le vecteur de commande C2 autorise I'expor- 
tation vers le second systeme de traitement de donnees situe a distance. 

so 

14. Precede selon la revendication 10, pour produire un premier code gen6re qui est uniquement operationnel dans le 
systeme de traitement de donnees qui est un systeme de traitement de donnees a distance, et un second code 
g6ner6 qui peut §tre importe a partir d'un dispositif d'utilisation connecte au systeme local, dans lequel le premier 
code K1 est le code principal, qui autorise seulement un usage operationnel dans le systeme de traitement de 

55 donnees local et le second code K2 est un code de cryptage de code KEK2 avec un vecteur de commande associe 

C2 et le vecteur de commande C2 autorise 1'importation a partir du dispositif d'utilisation vers le systeme local. 

15. Precede selon la revendication 10, pour produire un premier code genere qui peut etre importe a partir d'un dispositif 



110 



EP 0 356 065 B1 



d'utilisation connects au systems de traitement de donnSes qui est un systeme de traitement de donnees local et 
un second code gSnSrS qui peut etre exports vers un systeme de traitement de donnees situS a distance connects 
au systeme local, dans lequel le premier code K1 est un code de cryptage de code KEK1 avec un vecteur de 
commande associS C1 et le vecteur de commande C1 autorise I'importation a partir du dispositif d'utilisation et le 
5 second code K2 est un code de cryptage de code KEK2 avec un vecteur de commande associS C2 et le vecteur 

de commande C2 autorise Importation vers le second systeme de traitement de donnSes situS a distance. 

16. ProcSdS selon Tune quelconque des revendications prScSdentes, pour effectuer un re-chiffrage a partir d'une fonc- 
tion de code principal, qui comprend en outre un moyen de controle pour controler le vecteur de commande C1 

io associS au code de cryptage de code KEK pour assurer que le re-chiffrage a partir de la fonction de code principal 

est autorisee et contrdler que le vecteur de commande C2 associe au code K autorise le fait que le code K peut 
etre exports en utilisant le re-chiffrage a partir de la fonction de code principal. 

17. ProcSdS selon la revendication 16, dans lequel le vecteur de commande associS C3 permet de maniere selective 
'5 au processeur situS a distance de re-exporter le code cryptographique K. 

18. ProcSdS selon la revendication 1 6, dans lequel le vecteur de commande C1 associe au code de cryptage de code 
KEK est contrdle pour assurer que le re-chiffrage a la fonction de code principal est autorisS. 

20 19. ProcSdS selon la revendication 16, dans lequel le vecteur de commande C3 recu en provenance du systeme de 
traitement de donnSes situS a distance, permet de maniere selective une autre re-exportation du code K a partir 
du systeme de traitement de donnSes local. 

20. ProcSdS selon la revendication 16, dans lequel le vecteur de commande C2 est Stabli de maniere selective par le 
2S syteme de traitement de donnees local pour permettre une autre re-exportation du code cryptographique K depuis 

ie systeme de traitement de donnees local. 

21. ProcSdS selon Tune quelconque des revendications prScSdentes, pour effectuer une fonction de code de transfor- 
mation, comportant le controle du vecteur de commande C1 associe au code de cryptage de code d' importation 

30 KEK1, pour assurer que KEK1 est autorise sous la forme d'un code de cryptage de code d'importation dans la 

fonction de transformation de code et le vecteur de commande C2 associe au code de cryptage de code d'expor- 
tation KEK2 de maniere a assurer que le KEK2 est autorisS sous la forme d'un code de cryptage de code d'expor- 
tation dans la fonction de code de transformation. 

35 22. ProcSdS selon Tune quelconque des revendications 1 a 9, pour effectuer le re-chiffrage a partir de la fonction de 
code principal avec une reduction dans I'autoritS d'exportation pour le rScepteur, comportant le controle du vecteur 
de commande C1 associe au code de cryptage de code KEK pour assurer que le re-chiffrage a partir de la fonction 
de code principal est autorise et le vecteur de commande C2 associe au code K autorise que le code K peut etre 
exports en utilisant le re-chiffrage a partir de la fonction de code principal. 

40 

23. ProcSdS selon Tune quelconque des revendications prScSdentes, dans lequel le vecteur de commande associS 
comporte un champ dSfinissant une commande de liaison qui spScifie si un vecteur de commande associS avec 
un code cryptographique peut Stre supprimS de la transmission enter le systeme de traitement de donnSes et un 
systeme de traitement de donnees situS a distance qui lui est connects Stant donne les caractSristiques du systeme 

45 de traitement de donnSes situS a distance. 

24. ProcSdS selon Tune quelconque des revendications prScSdentes, dans lequel le vecteur de commande associS 
comporte un champ pour dSsigner si le code cryptographique est un code d'une seule longueur ou un code de 
longueur double. 

so 

25. Systeme de traitement de donnSes qui traite des demandes de service cryptographique pour la gestion de codes 
cryptograph iques qui sont associSs avec des vecteurs de commande dSfinissant les fonctions que chaque Smetteur 
lui permet d'effectuer comprenant: 

ss une installation cryptographique (4) comportant une limrte de sScuritS (6) par laquelle passe un trajet d'entrSe 

(8) pour recevoir les demandes de service cryptographique, des codes cryptographiques et leurs vecteurs de 
commande associSs, et un trajet de sortie (8) pour lui fournir des rSponses, Stant inclus dans la limite (6) une 
mSmoire (10) destructions cryptographiques couplee au trajet d'entrSe, un moyen (14) de controle de vecteur 
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de commande et un moyen (16) de traitement cryptograph ique couple a la m6moire d'instructions, et une 
m§moire (18) de code principal couplee au moyen de traitement (16), pour foumir un emplacement de s^curite 
pour executer les fonctions de gestion de code en reponse aux demandes de service recues; 
la m6moire (10) d'instructions cryptograph iques recevant sur le trajet d'entree (8) une demande de service 

5 cryptographique pour effectuer une fonction de gestion de code avec un code cryptograph ique; 

le moyen (1 4) de controle de vecteur de commande ayant une entree couplee au trajet d'entree (8) pour recevoir 
un vecteur de commande (figure 10) associe au code cryptographique et une entree connected a la memoire 
(10) d'instructions cryptographiques, pour recevoir des signaux de commande afin d'initier le controle du fait 
que ie vecteur de commande autorise la fonction de gestion de code qui est demandee par la demande de 

10 service cryptographique; et 

le moyen (1 4) de controle de vecteur de comamnde ayant une sortie d'autorisation (20) connectee a une entree 
du moyen (16) de traitement cryptographique, pour signaler le fait que la fonction de gestion de code est auto- 
risee, dont la reception par le moyen (16) de traitement cryptographique inrtie la performance de la fonction de 
gestion de code demandee avec le code cryptographique. 
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FIG. 4. 
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FIG. 13. 
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FIG. 22. 
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FIG. 24. 



CV TYPE 
TOKEN 000 


EXPORT 
CONTROL 


AV 


SOFTWARE 
CV Usage 
versi on 


EXTENSION 


RESERVED 


PARITY 


4b 3b 


lb 


2b 


6b 6b 


2b 


32b 


8b 


CF 


CF 


CF 


CFAP 


CF 


CF 


CF 



126 



EP 0 356 065 B1 



FIG. 25. 
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FIG. 27. 
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F/G. 31. 
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FIG. 32. 
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FIG. 33. 
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FIG. 36. 
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FIG. 38. 
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F/G. 39. 
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FIG. 40. 



CI 



CF 



output— type 



KM- 



KM. CI 



CONTROL 

VECTOR 

CHECKNG 

CI 



Random key 
generator(K) 



If output-type=0 then 64 bit odd parity 

adjusted random number; 
If output-typQ=l then 64 bit no parity 

random number; 
If output-type=2 then 64 bit odd parity 
adjusted key encrypted under KM with Ci; 



CC 



K 

or 

eXKM .C1(K) 



138 



EP 0 356 065 B1 



CI 



CF 



FIG. 41. 



KM- 



KM. CI 



CONTROL 

VECTOR 

CHECKNG 

CI 



super 


secure 


mode 


flag 



cv type (CI) 



If cv type (CI) = 'data/priv 1 or •token' then 
e*KM. CI (K) else 

(supersecure mode = 1) then 
e*KM.Cl(K) else ADORT . 



CC 



e*KM . CKK) 



139 



EP 0 356 065 B1 



FIG. 42. 
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FIG. 43. 
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FIG. 46. 
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FIG. 49. 
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FIG. 51. 
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FIG. 54. 



e*KM . CI L C KKl ) 
key— type 
CF 



e*KM.ClR(KKR) 



e*KKo(K) 



cntr 



C1L C1R C2 



C3 



cntr 



key— 
type 



KM C1L 



eXKKoCK) 



cntr 



KM C1R 



KM C2 



I L _l 



KM.C2 



EDE 



KM C3 



KM.C3 



EDE 



CV CHECKING: 
C1L,C1R,C2,C3 



C3 C1L C1R C2 



eKKKo(K) 



KM.C1L 




DED 




XOR 







KKL o 



cntr 



KM.C1R 




DED 






»■ 




XOR 



KKRo 





- eMKM.C2(K) 


If 


key— type = 0# Then 




R = e*KM . C3 (K ) 


If 


key— type = 1 » Then 




R = undefined. 


L 


R 



1 

CC 



eXKM.C2(K) 



<o*KM.C3CK)> 



149 



EP 0 356 065 B1 



FIG. 58. 
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FIG. 59. 
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FIG. 61. 
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F/G. 65. 



CA Instructions 
Koy Management Requirement to be used 


Master 
key 

\ x\\ t i al i z • 


■ Manual entry of master key IFMKP, CMKP, CVP (not 

mandatory, see note 1) 

■ Master Key Activation SMK 


Key 

encrypt \ ng 
key 

i ni t i al \ z. 


■ Manual entry of key encrypting LFKP, CKP, CVP (not 
keys via physical interface mandatory, see note 1) 

■ Entry of key encrypting keys EMK 
via programming interface 


Generate 

Clear 

or 

clear/enc- 
rypted key 


■ Generate clear keys via KEYGEN 
programming interface 

■ Generate clear keys for KEYGEN, EMK 
distribution via courier 

and for local storage in 
encrypted form 


Generate 
keys 

for local 
use 


• Generate a key for local KEYGEN 
storage and use. 

■ Generate two copies of a key 
for local usage, each copy 
with different usage attributes, 
where the generated key is a 

a. data/privacy GENKEYSET (op— op mode) 

b. data/mac GENKEYSET (op-op mode) 
b. data/other subtypes Prohibited by CCA 

d. KEK Prohibited by CCA 

e. PIN key Prohibited by CCA \ 



Notes : 1. The LFMKP, CMKP, LFKP, CKP and CVP instructions are 
not mandatory. Every system can have its own system- 
dependent key loading instruction. 
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FIG. 66. 





CA Instructions 
Key Management Requirement to be used 


Generate 
Keys for 
local use 
and for 
export i ng 
to another 
node • 


■ Generate two copies of a key, 
with different usage attributes, 
1st copy for local use 

and 2nd copy for exporting 

to another node using a CV channel, 

where the generated key i s a : 

a* data/compatibility Not supported by CA 

b. data/other subtypes GENKEYSET Cop-ex mode) 

c. key-encrypting key GENKEYSET (op-ex mode) 

d. PIN/PEK GENKEYSET Cop-ex mode) 

• Generate two copies of a key. Not supported by CA 
with different usage attributes, 

1st copy for local use 

and 2nd copy for exporting 

to another node using a CV=0 channel. 

■ Generate a single copy of a KEYGEN and RFMK 
key for local use and for exporting 

to another node using a CV channel. 

* Generate a single copy of a 

key for local use and for exporting 
to another node using a CV=0 channel, 
where the generated key i s a : 

a. data/ compatibility key KEYGEN and RFMK 

b. data/ with other subtypes Prohibited by CA 

c. key-encrypting key Prohibited by CA 
c. PIN keys Prohibited by CA 
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FIG. 67. 
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key for local use and for 








exporting to n nodes using 








the CV=0 channel, where the 








generated key is a : 








a. dato/compat i bi 1 i ty 


KEYGEN and RFMK 






b. data/other subtypes 


Prohibited by CA 






c. key— encrypt i ng key 


Prohibited by CA 






d. PIN keys 


Prohibited by CA 






■ Generate a single copy of a 


KEYGEN and RFMK 






key for local use and for 








exporting to n nodes using 








the CV channel, where the 








generated key i s a key of 








any key typo. 
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FIG. 68. 



CA Instructions 
Key Management Requirement to be used 


Generate 
Sess i on 
keys 
or file 
keys for 
compat i b— 
i 1 i ty wi th 
CUSP/3846 


■ Generate a session key or a GENKEYSET Cop— ex mode) 
file key for compatibility 

with IBM 3848/CUSP and PCF 

■ Generate a session key, GENKEYSET (im-ex mode) 
SNA multi— domain 


Key 

Di st r i bu— 

t i on 
Center 


■ Generate 2 copies of a key* 

no local use, each with different 
usage attributes, 1st copy for 

O 1 orf ron 5 r Hi r i Km f t nn ^ r\ t\ \ 

nodo, using a CV channel, and 2nd 
copy for electronic distribution 
to a 2nd node, using a CV channel, 

a. data/compatibility not supported by CA 

b. data/other subtypes GENKEYSET (ex— ex mode) 

c. key-encrypting key GENKEYSET (ox— ex mode) 

d. PIN key GENKEYSET (ox-ox mode) 

■ Generate 2 copies of a key, Prohibited by CA 
no local uset each with different 

usage attributes* 1st copy for 
electronic distribution to a 1st 
node, using a CV=0 channel, and 2nd 
copy for electronic distribution 
to a 2nd node, using a CV-0 channel. 


Key 

Translati on 
Center 


■ Receive and translate keys TRANSLATE KEY 


Import of 
keys 


* Electronic import via the 
programming interface of 

a. data/compatibility, using RTMK 

a CV = Q channel 

b. any key type, using a CV RTMK 
channel 

c. any key type other than Prohibited by CA 

data/compatibility, using 
a CV=0 channel 
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FIG. 69. 



KEY STORAGE CRYPTOGRAPHIC FACILITY (CF) 




COMMS 
LINKS 



EXPORT 
CHANNEL 
(EX MODE) 



IMPORT 
CHANNEL 
(IM MODE) 



Note; EX MODE corresponds to encryption under a KEK-Sender. 

IM MODE corresponds to encryption under a KEK-Recei ver , 
OP MODE corresponds to encryption under Moster Key KM. 
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CV type/subtype 



FIG. 70. 



Channel Typo. 
CV only CV = 0 only ANSI 



data / privacy 
data / mac 
data / xlata 
data / comp 
data / ansi 



y 

y 
y 

y* 
n 



n 
n 
n 

y 
n 



n 
n 
n 
n 

y 



kek / sender 
kek / receiver 
kek / ansi 



y 
y 

n 



n 
n 
n 



n 
n 

y 



PIN / encrypting 
PIN / generating 



y 
y 



n 
n 



n 
n 



ICV / not applicable 

Key Part / not 
appl i cabl e 



x Note that a key of type/subtype = deta/comp (i.e.* a compatibility 
mode data key can be communicated on a CV channel using a control 
vector or on a CV=0 channel by stripping off the control vector. 



FIG. 71. 



Mode Cspecified 
in instruction) 


Link Control 
(in CV of KEK) 


Is combination 
val i d? 


CV 


CV 


yes 


CV 


cv=o 


no 


CV 


CV or CV=0 


yes 


CV 


not applicable 


no 


CV = 0 


CV 


no 


CV = 0 


CV = 0 


yes 


CV = 0 


CV Or CV=0 


yes 


cv=o 


not appl i cnbl o 


no 
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FIG. 72. 





q* KEKac . C 1 ( KD) 




e*KEKcb.Cl(KD) 












D 


A 




C 





C converts e*KEKac . CI ( KD) 
to eKEKcb.C3(KD) 



FIG. 73. 



L*boll, C1U C1R, e*KM .ClL(KEKll) » E*KM . CIRC KEK1 R ) 
tabe!2, C2L , C2R, e*KM . C2L ( KEK2 L ) , E*KM.C2R(KEK2R) 
labe!3, C3L, C3R $ e*KM. C3L ( KEK3L) , EXKM . C3R C KEK3R ) 



Labeln, CnL, CnR, eXKM. CnL (KEKnL ) , EXKM. CnRCKEKnR ) 



FIG 74. 



1 

KEY 

storage| 
managers 

I 



KEY 
STORAGE* 



CFAP 



ANSI 
KEY 

MANAGER 



COMMUNI- 
• CATIONS 
SERVICES 



Other 
ANSI X9.17 
Nodes 



CF 
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FIG. 75. 



KEY STORAGE MANAGER 



I/O Service Calls 
or Memory Reference 
Instruct \ ons 



KEY STORAGE 


Lbll 


Keyl 


CV 


CTRs 




Lbl2 


Key2 


cv 


CTRs 














Lbln 


Keyn 


CV 


CTRs 


• • • 



CF 




Current XKM 






Working Key 






Reg i ster s 






etc . 







CFAP 



funct i on 

Colls: 

X Retrieve 

Key 
X Store 

Key 
x Delete 

Key 



Inst ruct i on 
References : 
X ARFMK 
X ARTMK 
X ACOMDKD 
X APNOTR 



ANSI KEY MANAGER 



Macro Calls: 
X AEDCVER 
X AKEYGEN 
X AMACGEN 
X AMACVER 
x etc. 
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FIG. 77 



RSI 



RTR 



KEY STORAGE 



GKKM.Cl(KKKac) 
Rcv_Ctr_KKKac 



KEY 


STORAGE 


e*KM . 


CICHKKac) 


Send_ 


.Ctr_*KKac 


e*KM. 


Cl(*KKbc) 


| Send_ 


.Ctr_*KKbc 



Node C 



RSI 



KSM 



RSM 



Node A 



KEY STORAGE 



eKKM.Cl(KKKbc) 
Rev Ctr KKKbc 



Node D 
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FIG. 78. 



RFS 



RTR 



KEY STORAGE 



eXKfl . CI ( xKKac ) 
Send_Ctr_*KKac 



Node A 



KEY STORAGE 



e*Kt1.CK*KKac) 
Send_Ctr_*KKac 
Rcv_Ctr_*KKac 



eHKM.ClCKKKbc) 
Send_Ctr_*KKbc 



Node C 



RSI 



KSM 



RSfl 



KEY STORAGE 



GKKM.Cl(KKKbc) 
Rcv_Ctr_*KKbc 



Noda B 
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FIG. 79. 



ENV 


NOD 


RCVS 


FROM 


UNDR 1 


GENS 


STORES 


UNDR 2 


SNDS 


TO 


UNDR 3 


SUP? 












Y If 


If it 1 1 Y If 


Ml/ M 


if if 


if rr 


* M\.a c 


m u 


A ■ 








XKK 


XKK 


XKMa 


XKK 


KTC 


XKKac 


YES 


KTC 




KK 


A 


XKKac 




KKI |KK 
( temp) 


xKMc 


KK 


B 

via A 


XKNcb 


YES 


KTC 


XKK 


A 


XKKac 




XKK 
C temp) 


XKMc 


XKK 


B 

via A 


XKNcb 


YES 


B 


KK 


KTC 
via A 


XKNcb 




KK | |KK 


xKMb 








YES 


*KK 


KTC 
via A 


XKNcb 




XKK 


XKMb 








YES 


KDC 


NOT APPLICABLE 


P-P 


A 








KK 


KK| IKK 


XKMa 


KK 


B 


KKab 


NO 


xKKab 


NO 


KNab 


NO 


XKNab 


NO 


XKK 


XKK 


XKMa 


XKK 


B 


XKKab 


YES 


XKNab 


YES 


B 


KK 


A 


KKab 




KKI |KK 


XKMb 








YES 


XKKab 




YES 


KNab 




YES 


KKNab 




YES 


XKK 


A 


XKKab 




XKK 


KKMb 








YES 


i 


KKNab 




YES 
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F/G. 76. 



ENV 


NOD 


RCV5 


FROM 


UNDR 1 


GENS 


STORES 


UNDR 2 


SNDS 


TO 


UNDR 3 


SUP? 


p-p 


A 








KD 


KD 


*KMa 


KD 


D 


new 
KKab 


NO 


new 
XKKab 


YES 


KKab 


YES 


XKKab 


YES 


KNab 


YES 


XKNab 


YES 


B 


KD 


A 


new 
KKab 




KD 


xKMb 








YES 


neu 
XKKab 


YES 


KKab 


YES 


XKKab 


YES 


KNab 


YES 


XKNab 


YES 



KEY STORAGE 



oXKn.CMKKKab) 
Send_Ctr_XKKab 



Node A 



KSM 



+ 3- 



RSI 



RSM 



KEY STORAGE 



oXKn.Cl(KKKab) 
Rcv_Ctr_XKKab 



Node B 



FIG. 80. 
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FIG. 81. 



ENV 


NOD 


RCV5 


FROM 


UNDR 1 


GENS 


STORES 


UNDR 2 


SNDS 


TO 


UNDR z 


SUP? 


KDC 


KDC 








KD 


KD 

( temp) 


KKflc 


KD 


A 
ond 
B 

via A 


KKNca 

and 
KKNcb 


YES 




A 


KD 


KDC 


KKNca 




KD 


KKMa 








YES 




B 


KD 


KDC 
via A 


* KNcb 




KD 


KKMb 








YES 












KDmac 


KDmac 
( temp) 


KKMa 


KDmac 


KTC 


new 
KKab 


NO 




A 








new 
KKKab 


YES 










KD 


KD 


KKMa 


KD 


KTC 


KKKac 


YES 












B 


new 
KKKab 


YES 






KDmac 


A 


new 
KKab 




KDmac 
( temp) 


KKMc 








YES 


KTC 


KTC 


new 
KKKab 










YES 




KD 


A 


KKKac 




KD 
C temp ) 


KKMc 


KD 


B 

via A 


KKNcb 


YES 








A 


new 
KKab 




KD 


KKMb 








YES 




B 


KD 


new 
KKKab 










YES 








KTC 
via A 


KKNcb 




KD 


KKMb 








YES 
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F/G. 82. 



Al 



ICV 

s 

byt os 



6 bytes 



XOR 



KEY- 




8 bytes 



CINIERTEXf 
8 bytes 



KEY- 



8 bytes 



CIPMERTEXT 
Encrypt i on 

F/G. 83. 




8 bytes 



Decrypt \ on 



A2 



8 bytes 



XOR 



KEY— 
64 

bits 
( i nclude 
8 parity 
bits) 

El 



KEY- 



8 bytes 



8 bytes 



E2 




An 



8 bytes 



KEY- 



XOR 


\ 


r 


1 





**OCV 

8 bytes 



En 
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FIG. 84. 



El 



KEY— 
bits 



E2 



8 bytes 



ICV 
8 bytes 



XOR 



KEY- 



8 bytes 



En-1 

8 bytes 



XOR 



8 bytc3 



KEY- 



En 



8 bytes 



Al 



KEY- 



8 bytes 
*0CV 



XOR 






XOR , 





A2 



8 bytes 
An-1 An 



8 bytes 



Al 



F/G. 85. 

A2 An-1 



KEY- 



E 




KEY- 


E 




01 




|o2 



XOR 




XOR 







An 



XOR 



KEY- 



On-1 



XOR 



KEY- 



On 



-<OCV) 



MAC 
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FIG. 86. 



INST • 


EQUATIONS 


ENC 


KD,A ► eKD(A) ECO Mode, 8 byte data and key, encode 


DEC 


KD 9 eKDCA) A : ECB Mode, 8 byte data and key, decode 


ENCI 


eXKM.Cl(KDl),ICV,A,n,Cl ►eKDlCICV,A) encipher op 


DECI 


eKKM.Cl<KDl),ICV,oKDI(ICV, A),n,Cl ►A decipher op 


GMAC 


eKKM.Cl<KDl),<eKKH.C2CKD2>>, 
ICV <eHKM.C3(0CV)>, A ,n, 

i cv— type, output— type, mac— enc, CI , <c2> , <C3> — »-MAC(64 bit) 

or 

e*KM.C3<0CV> 


VMAC 


e*KM.Cl(KDl) ,<e*KM.C2(KD2)>, 
ICV <qXKM.C3C0CV>>, A $ ' MAC , n , 

\ cv— type , output— type $ mac— one , CI * <C2> > <C3> yes/no 

or 

eXKM.C3<0CV) 


TCTXT 


eKKM.CKKDl) ,ICVl,eKDlCICVl, A) , 

eXKM.C2(KD2),ICV2, n,Cl,C2 ► eKD2CICV2,A) 
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FIG. 87. 



INST. 



EQUATIONS 



GKS 



op— op 
op—ex 



mode, C3# C4 



e*KM . C3< K ) » e*KM.C4(K) 



op— i m 



mode, C2L , C2R, C3, C<t , e*KM . C2L ( KKE2L) , 

e*KM .C2RCKKE2R) ► eXKM . C3 ( K) , eXKEK2.C4(K> 

mode, C1L, C1R, C2L , C2R * C3, C4 , 
eXKM.ClL(KKElL) , eXKM .C1RCKKE1R) , 
eXKM .C2LCKKE2L) , eXKM . C2RC KKE2R ) 

eMKEKl .C3(K> , eXKEK2 . ( K ) 

same as op— ex 



i m— ex : same as ex— ex 



RFMK 



di st-mode, eXKfl.ClLCKEKIL) ,eXKM.ClR(KEKlR) , eXKM . C2 ( K ) , 
C11,C1R,C2,C3 eXKEKl . C3 ( K) 



RTMK 



di st-mode, eXKM.ClLCKEKlL), eXKM . CIRC KEK1R) , eXKEKl . C3 CK) , 
C1L,C1R,C2,C3 eXKM.C2CK) 



KGEN 



output— typo, Cl- 



K op 
eXKM.CICK) 



EMK 



K.Cl 



eXKM.CICK) 



XLTKEY 



eXKM.CUCKEKlL ) ,eXKM.ClR(KEKlR) , 
e*KM.C2L(KEK2L) , eXKM . C2RC KEK2R > ,eXKEKl .C3CK) , 
C1L,C1R,C2UC2R,C3 ^ e*KEK2.C3(K) 



RTNMK 



mode,eXKMC-CKK>, CI 



eXKMN • CI (K) 



RTCMK 



modceXKMO.CICK), CI 



gKKMC.CKK) 



SMK 



MDCOP 



♦ NMK flag reset 
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FIG. 83. 



INST . 


EQUATIONS 


CLRCF 


clears all the registers in the crypto facility \ 


CLRKPR 


clears the key part register 


CLRNMK 


clears the new master key register 


LCVA 


e*KM.Cl(K),Cl,C2 ► e*KM.C2(K) 


LFMKP 


() »• KP register transferred to NMK register 


CMKP 


mode ^ NMK register = NMK register XOR Keypart register 


LFKP 




CKP 




CVP 




APHOTR 


mode , e*KM. ClL(KKl) , e*KM. ClR(KKr) , FMID, TOID, C1L , C1R, C2L , C2R 
^ e*KM . C2L ( KKNIL ) , e*KM . C2R(KKNIR) 


ARFMK 


e*KM*ClL(KKL <KKNIL> ) $ e*KM.ClR(KKR <KKNIR> ) , 
e*KM. C2CKEY) * cntr • CI L , C1R , C2 eXKK(KEY) 


ARTMK 


e*KM.ClL(KKL <KKNIL> ) , e*KM . CI R < KKR <KKNIR> ) , 
e*KK( KEY), cntr, key-type, C1L , C1R , C2 , <C3> 

e*KM.C2(KEY), e*KM - C3( KEY > (for KD) 

► eKKM.C2(KEY) (for KK) 


AXLTKEY 


eKKM.ClKKKIL <KKNIll>), e*KM„ C1R( KK1R <KKNI1R>), 
e*KM.C2L(KK2L <KKNI2l>), e*KM. C2R ( KK2R <KKNI2R>), 
e*KKl (KEY), cntr l,cnt r2, key-type, CI I , C1R , C2L , C2R, C3 

e*KK2(KEY), c*KM.C3(KEY) (for KD) 

► e*KK2(KEY), e*KM . C3 ( KDmac ) (for KK) 


ACOMBKD 


e*KM . CI ( KD1 ) » e* KM . C2 ( KD2 ) , C1,C2,C3 c*KM . C3 ( KD ) 
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